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

[Paul Cercueil]

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.

Cheers,
-Paul

> 
>   For now, probably should have a special instruction and since the
> third
> argument is not used, make it a bitfield telling what direction and
> if
> before or after.
> 
> > Marc
> 
> Thanks!
> Paulo