Re: [libre-riscv-dev] Yehowshua Tasks

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

one fundamental aspect of what we are doing: anything that has the
slightest possibility of causing "irreversible damage" absolutely has to
have both a "hold off" and "go die" signal.

nothing and i mean nothing can be allowed to proceed unless it has a 100%
chance of success because we are *not* doing a "transaction / rollback /
history" system, we are doing a *shadow* (write-hold) system.

if there is any possibility of a memory write causing an exception, that is
the *very definition of causing damage*!

the memory write therefore must be subdivided into two phases:

1) to check if the write WOULD succeed ***IF*** permitted to proceed

2) after notification and receiving permission to proceed, ***ONLY*** then
proceeding with the actual commit to memory.

this has implications as i understand it even for the L1 Cache.

it is *not* ok to have phase 1 proceed, the notification go back, "yes
there is room in the cache for you" followed in phase 2 "actually i lied,
we need to raise an exception now".

so to make this clear:

* phase 1 is the only time that exceptions can be raised.

* phase 2 is absolutely fundamentally the part where no exceptions of any
kind can be raised.  the write MUST occur... or if it genuinely cannot we
will be required to halt the processor as it is a serious critical mistake
on our part or fundamental data corruption event, from the hardware.

this has implications that phase 1 may need to "hold" resources (reserve
cache lines, reserve TLB entries) for a short duration until it receives
either the "proceed" or "cancel" signal.

i do not know if Minerva L1 can handle that because there is zero code
comments.

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