[libre-riscv-dev] [Bug 139] Add LD.X and ST.X? Strided

[bugzilla-daemon at libre-riscv.org]

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

--- Comment #53 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
read everything, still absorbing.  i see where you're going with the
"type-safety".

the immediate problem i can see with it is: predication (single or twin)
*already* makes the concept of bounds-checking runtime type-safety moot.
predication is *already* run-time-dependent, and developers (and
compilers) already have to "put up with" it, and make damn sure that they
get things right.

have to pack, ready for tomorrow, so will be a little distracted.

i do like [f]swizzle2 (rs1==rs3).  can you demonstrate *exact* equivalence
i.e. that src *and* dest may have elements arbitrarily "skipped" i.e. not
destroyed?

how is the following achieved?

   rd.yw = rs.zy

using twin-predication (twin "masks" - however they are called, i don't
care if they're named "unknown" or not) - it is dead-easy.  dest mask
equals 0b0011.

ah.

wait.

just listing that example, something just occurred to me.

you don't need twin-predication.  you need *single* predication, on the dest.

the reason is: the src-index-selection gives "appearance" of twin-predication.
with the dest having predication, all you do is: fill in *only two* src
swizzle indices.

*smacks-forehead*...


> 6. Not needing a popcount (even though it's quite small) simplifies
> instruction decode

it's not for decode, it's for exception-recovery after a context-switch.
it is absolutely the case that popcount would *not* be needed when
*starting* a newly-issued instruction because the offsets start at zero.

only when one of the offsets is not zero (returning from an exception)
does the other need to be recovered.

however this i believe is now moot as i realised twin-predication is
redundant.  can you confirm / check the logic/reasoning above?

will go over the rest (inline) again.

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