[libre-riscv-dev] [Bug 186] Create decoder for SOC

bugzilla-daemon at libre-riscv.org bugzilla-daemon at libre-riscv.org
Mon Feb 24 21:26:48 GMT 2020


--- Comment #18 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #16)
> (In reply to Jacob Lifshay from comment #14)
> > My issue is not that it can't be implemented correctly in HW, but that
> > having the instruction switch the address used halfway through makes it much
> > harder to use in a compiler due to the inputs being overwritten part way
> > through execution.
> > 
> > It's the difference between load1 and load2 in:
> note that switching to load1 will require a CSR to store the address if the
> instruction is interrupted in the middle because the address register may
> have already been overwritten.

the modifications by mitch alsup to the 6600 system do not require that to

specifically: the "shadow" mechanism.

the "shadow" mechanism allows for "damaging" consequences to be *calculated*
but *prevented and prohibited* from actually hitting memory, register file,
or other critical non-reversible resource.

if there is anything that could raise an exception which could
cause "damage", it raises a "shadow".

ONLY when the result of the operation is GUARANTEED to complete is the
shadow released.

there *is* no possibility, therefore, of damage occurring by an instruction
being "interrupted in the middle".

the operation therefore either completes atomically... or its results discarded
entirely, and, because the shadow is also cast across *subsequent* instructions
as well, all instructions in sequence after the one being discarded are also

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

More information about the libre-riscv-dev mailing list