On Tue, Jul 02, 2019 at 11:41:35AM +0100, Andrew Haley wrote:
> On 7/2/19 6:37 AM, Zdenek Sojka wrote:
> > Ok, shame - it seems to behave so in my experiments:
>
> It's more complicated than that. Sometimes the size of the operand is
> in the name of the instruction and sometimes you need to force the
> size yourself.
You also need to consider the mode that is used for the variables.
> For example, with int a, x:
>
> asm("mov %1, %0" : "=&r"(a) : "r"(x));
>
> generates
>
> mov %edx, %eax
and with "short a, x" you get %ax and %dx, and with "char a, x" you get
%al and %dl without needing the %b output modifier.
> I'm a bit paranoid about this stuff because my memory of GCC's inline
> asm goes back decades to when it was far more fragile than it is now.
Oh it still is quite fragile / does unexpected things whenever you try
anything out of the ordinary. For example, operands do not get the
usual integer promotions, as the example above shows: operands are
treated like lvalues instead, input operands as well.
If you know what mode is used for every operand you use in asm, and/or
you just use operands that are full register size, there aren't many
surprises.
Things get even more interesting if you use multi-register modes, like
DImode with -m32 on x86. On x86 that says "warning: unsupported size
for integer register", but some other targets have to handle that.
Writing correct asm in such cases of course means that you have to know
what the compiler does.
Segher
