Re: Unaligned load/store opcodes

[Paulo César Pereira de Andrade]

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.

  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.

Thanks!
Paulo