[libre-riscv-dev] [Bug 48] Complete IEEE754 floating point pipeline

[bugzilla-daemon at libre-riscv.org]

http://bugs.libre-riscv.org/show_bug.cgi?id=48

--- Comment #4 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Luke Kenneth Casson Leighton from comment #1)
> comment from jacob (to be discussed to create separate milestones):
> 
> particular,  I'm planning on having the div pipeline also handle integer
> div/mod and having the main pipeline handle integer multiplication and
> probably additional operations.

bear in mind in an OoO (parallel) design, keeping the units separate allows
the developer to decide *how many* of each ALU type shall be deployed, and then
to pass in a part-encoded instruction which tells the pipeline what action
to take.

i would greatly prefer there not to be massive code-duplication between
the single-core barrel processor and the multi-core OoO one because the
pipelines designed for one cannot be used in the other!

would it be ok to design the ALUs to have the *option* to cover multiple
functions, by way of being constructed from an API-selectable *range*
of available pipelineable (and FSM-based) units?

the reason that i ask is because, if you look at Mitch Alsup's 2nd book
chapter, you will see a detailed assessment of how to design a suite of
pipelines based on performance requirements that go so far as to analyse
the application requirements from a statistical analysis perspective...

... and then *specifically* target the design of the pipeline suite *and*
the register file port count to that *specific* analysis.

if the pipeline is specifically *hard-coded* to *require* that it handle
integer and DIV, that type of analysis and specific design targetting is
no longer possible.

-- 
You are receiving this mail because:
You are on the CC list for the bug.