Re: Unaligned load/store opcodes

[Paul Cercueil]

Hi Paulo,

Le lundi 27 mars 2023 à 12:14 -0300, Paulo César Pereira de Andrade a
écrit :
> Em qui., 23 de mar. de 2023 às 13:50, Paulo César Pereira de Andrade
> <paulo.cesar.pereira.de.andrade@gmail.com> escreveu:
> > 
> > Em qui., 23 de mar. de 2023 às 08:07, Paul Cercueil
> > <paul@crapouillou.net> escreveu:
> > > 
> > > Hi Paulo,
> > 
> >   Hi Paul,
> > 
> > > I think Lightning would benefit from having support for 16/32/64-
> > > bit
> > > I/O to unaligned addresses. That's something I would actually
> > > use.
> > > 
> > > Something like:
> > > ldur_s / ldur_us / ldur_i / ldur_ui / ldur_l
> > > stur_s / stur_i / stur_l
> > 
> >   These can be added and fallbacks are mostly trivial.
> > 
> > > I don't think we need ldx/stx variants.
> > 
> >   For completeness, and unless there is an specialized version for
> > ldx/stx a simple wrapper adding register values is easy.
> 
>   Using named versions would use too many jit_code_t values
> for a complete set of something that has very few special use cases.
> 
> > > What do you think?
> > 
> >   Most cpus have some kind of help for unaligned read, or just
> > transparently allow it, but slower load/store.
> 
>   Maybe we could think of something like:
> 
> unldr   output base size
> unldi   output base size
> unldr_u output base size
> unldi_u output base size
> unsti   base output size
> unstr   base output size
> 
> and could be useful:
> 
> unldr_f output base
> unldi_d output base
> unstr_f base output
> unsti_d base output
> 
>   The versions with a register base could have an extra immediate
> offset argument. But for consistency, better to not have this extra
> immediate.
> 
>   Since only bytes are addressable, size would be in bytes, and would
> also allow words of 3 bytes, and 5, 6 and 7 bytes for 64 bit.

Do we really need this? ... The unaligned load/store would be useful
for loading from unaligned fields in a C struct, for instance, but the
fields themselves are always 1/2/4/8 bytes, so I don't know in which
case you would need to load 3/5/6/7-byte "words".

>   The float and double ones are just for convenience, and in most
> cases
> are used for a double aligned at 4 bytes boundaries. There are 2 (or
> other
> values) byte floats, but these are usually only in software, and
> would be
> too much for lightning, which does not have any kind of soft float
> support.

I know that on MIP32r2 for instance you have LWL/LWR/SWL/SWR for
unaligned accesses, but I'm not aware of any mechanism to load/store
floating-point on unaligned boundaries. You can't even load it into a
GPR, because (at least on MIPS) there would be no way to transfer that
value into a FPR. So I'd drop the _f/_d variants.

Unrelated, but it's a bit confusing to have "ext" and "extr"
instructions, could we maybe find a better name?
"jit_extbr" for "extract bits"
or "jit_maskr" for "extract mask"
as two random suggestions.

Cheers,
-Paul