Re: Specifying different registers in inline asm

Le 2025-11-19 14:56, Segher Boessenkool a écrit :
> Hi!
> 
> On Wed, Nov 19, 2025 at 09:03:53AM +0100, [email protected] wrote:
>> Le 2025-11-18 18:10, Segher Boessenkool a écrit :
>> > The first copy it into a variable that *is* writable?  This is required
>> > for correctness, since your asm *does* modify the reg!
>> I'm not sure about this situation, for me there are two sides on this
>> matter: a practical one and a theoretical one.
>> On the practical side, the instruction does a write back to the 
>> register,
>> but with the same value
> 
> Then, as far as the compiler is concerned, you did *not* write it at
> all.  There is no way to see the difference, anyway -- "memory refresh"
> is not modeled at all either.
Yes, this confirms what I thought, and can serve (with great caution!) 
as an optimization and be differentiated between the 0-increment of this 
instruction and the real clobber (in the case of an unneeded value) of 
another (unspecified here, just for the sake of discussion) instruction 
that would necessarily modify the register.
> 
>> (because omission of the offset is equal to 0 in
>> this instance), so the register does not change value.
>> On a theoretical side, I would like to tell the compiler that the 
>> register
>> is clobbered, that I don't care about the value anymore, but that if 
>> the
>> compiler needs the value, it cannot rely on the fact that the register 
>> still
>> contains it. I think it is not possible to specify clobbers for input
>> values, but it makes sense to be able to use a non-lvalue here, so I 
>> don't
>> want to specify it as an output. Is this doable?
> 
> A clobber is a write with an unknown value (by definition), so it can
> only ever happen to something writable, so an lvalue if modeled in C.
I'm not sure I totally agree here, because the register gets the indexed 
array address (something like &buffer[counter]), which is not an lvalue, 
but the register itself can be written to (which is my situation, if I 
understand anything about it).
> 
> In inline asm you have output operands, input operands, and a clobber
> list.  The clobber list cannot validly intersect the output operands
> (if it would, you are describing some register is wriiten *twice*,
> atomically).
Ah maybe this is a mis-commitment of the information to my memory. Can 
clobbers intersect input values? (I thought they can neither intersect 
input nor output values). Output values are obviously incompatible with 
clobbers. I don't know why it would be forbidden for inputs, but the 
compiler sometimes moves in mysterious ways (and I as a mere mortal have 
to fight my instincts of demanding everything of it)... So maybe the 
confusion just comes from my misconception that an input cannot also be 
a clobber.
Why I mentioned the lvalue, is because I tried qualifying the address as 
"+r" to communicate that I modify the address (which MUST then be an 
lvalue), but the modification is actually an unwanted side-effect and I 
want to throw the value away.
> 
>> > > > > destination and the address register should be different (as helpfully
>> > > > > mentioned by the assembler: "destination register same as write-back
>> > > > > base").
>> > > > > The code generator produces "LDRBT R3, [R3]" which is not correct.
>> > > > > I would like to specify that I want two distinct registers for %0
>> > > > > and %1 (my
>> > > > > code is LDRBT %0, [%1]), but I did not find how.
>> > > >
>> > > > If you want literally what you ask for (but read above), what you want
>> > > > is an "earlyclobber".  Written as "&", see the manual.
>> > > >
>> > > Thank you very much, it is so obviously described, once you know
>> > > where to
>> > > look.
>> >
>> > As always :-)
>> >
>> > One thing you can try is "read everything".  I've been trying to do that
>> > forever now, and am still not done, but making some progress I hope ;-)
>> Nah, the real method is to "read everything an infinite number of 
>> times",
>> because on each pass you understand something that you have read 
>> before, but
>> which did not click into place. But as everyone knows eternity is very 
>> long,
>> especially towards the end.
> 
> There are only finitely many (but many) things described in the manual,
> so you can read everything by just reading it a finite number of times.
> Remembering it can be more tricky of course :-)
I was thinking about it as I wrote my sentence. I kept it that way first 
for the impact, and then for the fact that an unrelated event (at least 
in my experience) can click something in your brain that allows your 
next pass to understand something new (so the combinatorics are 
unfathomable). I have no idea how a photographic memory would work (and 
if reading it once could allow numerous references to every sentence, 
down to the spelling mistakes - of which I am sure there are none), but 
my own memory seems to work by associating concepts.
> 
> 
> Segher
JH