[libre-riscv-dev] elwidth override on LOAD/STORE

[Luke Kenneth Casson Leighton]

On Sun, Oct 28, 2018 at 6:24 AM Luke Kenneth Casson Leighton
<lkcl at lkcl.net> wrote:

> ok so i wrote up a sub-section on LOAD/STORE bitwidth polymorphism,
> https://libre-riscv.org/simple_v_extension/specification/#elwidth_loadstore

 now implemented the LD algorithm, added a preliminary batch of unit
tests that show the concept, it works really well.  basically it's
kinda "obvious" once the actual (scalar) algorithm is broken down into
its constituent parts: load from memory, sign/zero-extend, store in
register.

basically the LOADs get "funneled" through an elwidth re-shaper, which
could sign-extend, zero-extend or truncate, just like it does for any
other twin-predication: it's just that this time the source happens to
be coming from memory, *and* the *block width* of the source is set by
the operand width (LB/H/W/D) *not* by XLEN as is the case for
register-based twin-predication.

i also added some "example tables showing LOAD elements", because the
text - and even the pseudo-code - are a little hard to follow.
examples illustrate clearly some things that would otherwise be
missed, such as the fact that on an uneven block of LOADs (VL elements
modulo reg-width not falling on an exact complete register boundary),
the remaining parts of the register at the tail end of the hardware
loop 0..VL-1 are *unmodified*.

with predication being required to leave unmodified elements alone,
the hardware to do this will need to already be in place.

l.