[Libre-soc-isa] [Bug 572] elwidth and indirection: two vectors, one width

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=572

--- Comment #7 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #6)
> so, for `ld reg, imm(reg)`, the src elwidth specifies:
> 0 -- unit stride -- loads from reg + imm + load_size * element_index
> 1 -- strided with stride of imm -- loads from reg + imm * element_index
> written: ld reg, (reg), stride=imm
> 2, 3 -- reserved -- maybe split imm bits between offset and stride?

mmm there's only 16 bits (signed/unsigned), not too keen on limiting
expectations (and altering compiler from scalar behaviour)

RVV sets an "ordered/unordered" mode, which is interesting.

other options: select to use the *dest* elwidth as the unit stride multiplier. 
this will give some weird overlaps when using e.g. ld (64 bit) with dest
elwidth=8, and some stranger overlaps for ST.


also, it turns out that when RA is vectorised, unit stride is absurd nonsense.

     EA = iregs[RA+i] + i*imm

naah.  so i disable unit stride there and make it just:

     EA = iregs[RA+i] + i*imm

this leaves the "mode" bits doing nothing. what to do there? can we do anything
with the 2 bits?  put them back to src elwidth?


> written: ld reg, offset_imm(reg), stride=stride_imm
> 
> for `ld reg, (base_reg + index_reg)`, the src elwidth specifies the elwidth
> of index_reg, base_reg is always 64-bit.

yes, this is just necessary.
get_polymorphic_reg(RA, elwidth=64, i)

rather than elwidth=op_wid.

> similarly for store.

yes.  it's the EA (effective address)

question is, does "mode" do anything useful?  2 bits, 4 options... i'm honestly
not thinking of anything that really stands out except perhaps
ordered/unordered

hmmm

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