Re: [libre-riscv-dev] Introduction and Questions

[Luke Kenneth Casson Leighton <lkcl@lkcl.net>]

(appreciate the compiler analysis, Staf.)

On Saturday, May 16, 2020, Staf Verhaegen <staf@fibraservi.eu> wrote:

>
> Assume a write to a scratch register is still pending when doing a
> procedure. With real register renaming the register stack push does not
> need to block until write to register is complete, if it doesn't the
> register push will block.


fortunately if there are enough Function Units (their operand and result
latches being "storers of in-flight registers without any names"), the
pipelines can continue to produce results, and if there is an operand
forwarding bus the scratch register result can be passed on to other FUs to
continue further work - none of which hits the Register File... yet - all
without stalling.

it has been a year so the details are a little hazy, however i seem to
recall that a WaW with enough FunctionUnits plus operand forwarding will
just have a small one clock cycle penalty of the extra regfile write that
could be optimised out.

not, "total catastrophic performance drop".

the optimisation if i recall correctly involved detecting, at the
Dependency Matrices, that there was not only no reader of a given register
waiting for the result, but that there was an outstanding write as well.

i.e. WaW can only be optimised away if there is no reader *in between* the
two writes.

i.e. if there is W R W you cannot throw away the 1st W until the R has
happened.

this requires tracking of multiple Ws per register actually at the
Dependency Matrices, and that means literally doubling or tripling the size
of the matrices which are already going to be enormous.

hence why the decision was taken to shelve that one for later as it is the
kind of thing that matters for high performance.

l.





-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev