[libre-riscv-dev] Possible memory related paper and rust

[Luke Kenneth Casson Leighton]

On Wed, Feb 26, 2020 at 2:20 AM Jacob Lifshay <programmerjake at gmail.com> wrote:
> > I’m also not sure if the 6600 design already solves such problems.
>
> yes, it does by having separate instruction and data caches as well as a
> wider (128-bit, not sure) memory interface. Those reduce the memory
> bottleneck by allowing accessing instructions and data simultaneously
> (assuming the required data is in the caches).
>
> > I haven’t studied it in detail yet nor read the book chapters yet. Can
> you share them with me?
>
> Luke would be a better person to ask.

the primary reason for going with the 6600 design is that an
in-order's "solution-to-everything" is: stall.

output not ready from a pipeline result that is needed as an input on
the immediately-following instruction?

stall.

output from one pipeline takes longer because it has more stages?

stall for longer.

got an interrupt that needs servicing? you can't do anything (swap
context) until the entire pipeline is clear.  solution?

stall.

load data bus not ready?

stall.

stall. stall. stall. stall.

this gets incredibly tedious, very quickly.  industry-standard efforts
to "optimise" (workaround) stalls are some of the worst hacks i've
ever had the displeasure to read about, and am deeply unimpressed by.

by contrast, once you get your head round the triple-revolving-door
concept of GO_READ, GO_EXECUTE, GO_WRITE (only two of those are
permitted to be "ready" at any one time) and the roles of the twin
Dependency Matrices recording the relationships between
Registers-and-FunctionUnits (FUs) and FU-FU, the fact that these two
DMs "take care of everything" means that the entire design becomes

drastically,

DRASTICALLY

simpler.

consequently, all Function Units can be Finite State Machines,
pipelines, variable-length pipelines, early-out pipelines,
*dynamically* adjustable length pipelines, and the overall
architecture *literally does not care*, because it revolves around
"results" - when those results are available...

NOT

repeat

NOT

"how long will this result take and oh god i've got to schedule
reading from the output stage otherwise the result is lost and
corrupted oh hell oh hell why in god's name did i ever think an
in-order design was going to be soooo much simpler???"

l.