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

[Paulo César Pereira de Andrade]

Em seg., 18 de dez. de 2023 às 15:29, Paul Cercueil
<paul@crapouillou.net> escreveu:
>
> Le lundi 18 décembre 2023 à 15:23 -0300, Paulo César Pereira de Andrade
> a écrit :
> > Em seg., 18 de dez. de 2023 às 12:12, Marc Nieper-Wißkirchen
> > <marc.nieper+gnu@gmail.com> escreveu:
> > >
> > >
> > >
> > > Am Mo., 18. Dez. 2023 um 15:36 Uhr schrieb Paulo César Pereira de
> > > Andrade <paulo.cesar.pereira.de.andrade@gmail.com>:
> > > >
> > > > 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..
> > >
> > >
> > > The direction flag has to be cleared on function entry/exit; this
> > > is specified in the System V ABI.  The same is true for the Windows
> > > platform.
> > >
> > > The problem with the x86 instructions mentioned is that they only
> > > work on fixed registers, making them mostly unusable for GNU
> > > lightning.
> > >
> > > What would be interesting for x86 would be instructions exploiting
> > > addressing modes like in
> > >
> > > movq %rax,8(%rdx,%rcx,4)
> >
> >   My "simplification" is also broken. Need to know if before/after
> > and if
> > increment/decrement. So, it would be 4 instructions for every data
> > type.
> >
> > ld {increment,decrement} {before,after} _ {c,uc,s,us,i,ui,l,f,d}
> > st {increment,decrement} {before,after} _ {c,s,i,l,f,d}
>
> That would be 4 loads and 4 stores, I think we only need half of that.
> I really don't see the use of increment-before / decrement-after, given
> that these instructions are only really useful with stacks.

  It would be useful in some C like language. Arm has these, but
only for 32 bit integers (full register size).

  Aarch64 has interesting options:

...
* Base plus offset addressing means that the address is the value in
the 64-bit base register plus an offset.
* Pre-indexed addressing means that the address is the sum of the
value in the 64-bit base register and an offset,
  and the address is then written back to the base register.
* Post-indexed addressing means that the address is the value in the
64-bit base register, and the sum of the
  address and the offset is then written back to the base register.
...

> Cheers,
> -Paul

Thanks!
Paulo