Re: Idea : load/stores with pre-decrement / post-increment

[Paulo César Pereira de Andrade]

Em seg., 18 de dez. de 2023 às 07:08, Paul Cercueil
<paul@crapouillou.net> escreveu:
>
> Hi Paulo,

  Hi Paul,

> One pattern that I see quite often, is a store or load with address
> pre-decrement or post-increment. Something like this:
> addiu r0, r0, -1
> str_c r0, r1
>
> ldr_c r1, r0
> addiu r0, r0, 1
>
> Do you think it would make sense to have instructions for these?
> Something like:
>
> stdbr _c _s _i _l   O1 -= transfer size; *O1 = O2
> lddbr _c _s _i _l   O2 -= transfer_size; O1 = *O2
> stiar _c _s _i _l   *O1 = O2; O1 += transfer size
> ldiar _c _s _i _l   O1 = *O2; O1 += transfer size

  I like the idea.

> (stdbr/lddbr for "store decrement before" / "load decrement before",
> stiar/ldiar for "store increment after" / "load increment after")
>
> I know that ARM would support it, SuperH as well, and probably others.
>
> I do not think that it would need support for offsets (ldx*/stx*), the
> patterns I see always use a zero offset. I also do not think that we'd
> need pre-increment or post-decrement, or support for other values than
> the transfer size.

  Should check what other architectures provide. A quick check for x86*
shows https://www.felixcloutier.com/x86/lods:lodsb:lodsw:lodsd:lodsq
but setting the direction flag without global loop knowledge would
probably cost more than a fallback..

  If some architecture has a version with 3 registers that allow pre
increment or post decrement of the offset register, then a fallback
could be added for all other ports.

  Maybe use a shorter name, for example, instead of

ldiar_c have ldar_c
lddbr_c have ldbr_c

that is, instead of "(i)ncrement (a)fter" have only "(a)fter" and
"(d)ecrement (b)efore" have only "(b)efore"

  This can be added easily to the high level Lightning code as it is
already prepared for instructions that change multiple registers.

> Thoughts?

  I will try to work on a global implementation using only fallbacks
in the next few days, then, can slowly change the fallback call to
optimized code generation when available.

> Cheers,
> -Paul

Thanks!
Paulo