[x86 inline asm]: width of register arguments

[Zdenek Sojka]

Hello Andrew,

---------- Původní e-mail ----------
Od: Andrew Haley <aph@redhat.com>
Komu: Zdenek Sojka <zsojka@seznam.cz>, gcc-help@gcc.gnu.org
Datum: 29. 6. 2019 18:11:20
Předmět: Re: [x86 inline asm]: width of register arguments
"Hi,

On 6/24/19 1:19 PM, Zdenek Sojka wrote:
> how does gcc choose the register arguments of an inline assembler and what

> can I assume about the "unused" bits?

The choice is made by the register allocator.

You can't assume anything about the "unused" bits. The "r" register
constraint means you get a whole register to use, of the wordsize of
the machine.
"



Ok, that's a very important information!




I was a bit afraid that the compiler might assume the upper bits are eg. 
zeroed, if they were zeroed before the __asm__ statement. (or that high-
order bits might be sign-extension of the narrower value)


 
"

> My questions target the 64bit x86 architecture; I assume the behavior is
the
> same for all target triplets x86_64-*-*
>
> 1) does gcc always use register of size matching the size of the variable?


No. "



Ok, shame - it seems to behave so in my experiments:




void foo(void)
{
        uint8_t u8; uint16_t u16; uint32_t u32; uint64_t u64;
        __asm__ volatile ("# %0 %1 %2 %3" : "=r"(u8), "=r"(u16), "=r"(u32),
"=r"(u64));
        __asm__ volatile ("# %0 %1 %2 %3" : "+r"(u8), "+r"(u16), "+r"(u32),
"+r"(u64));
        __asm__ volatile ("# %0 %1 %2 %3" :: "r"(u8), "r"(u16), "r"(u32),
"r"(u64));
}





generates at all optimization levels (-O0 to -O3 8bit reg for u8, 16bit reg
for u16, 32bit reg for u32, 64bit reg for u64:




# 9 "tsts.c" 1
        # %al %dx %ecx %rsi
# 0 "" 2
# 10 "tsts.c" 1
        # %al %dx %ecx %rsi
# 0 "" 2
# 11 "tsts.c" 1
        # %al %dx %ecx %rsi
# 0 "" 2





Similar for:

void bar(uint8_t u8, uint16_t u16, uint32_t u32, uint64_t u64)
{
        __asm__ volatile ("# %0 %1 %2 %3" : "=r"(u8), "=r"(u16), "=r"(u32),
"=r"(u64));
        __asm__ volatile ("# %0 %1 %2 %3" : "+r"(u8), "+r"(u16), "+r"(u32),
"+r"(u64));
        __asm__ volatile ("# %0 %1 %2 %3" :: "r"(u8), "r"(u16), "r"(u32),
"r"(u64));
}





and for



void baz64(uint64_t a, uint64_t b, uint64_t c, uint64_t d)
{
        __asm__ volatile ("# %0 %1 %2 %3" :: "r"((uint8_t)a), "r"((uint16_t)
b), "r"((uint32_t)c), "r"((uint64_t)d));
}

void baz8(uint8_t a, uint8_t b, uint8_t c, uint8_t d)
{
        __asm__ volatile ("# %0 %1 %2 %3" :: "r"((uint8_t)a), "r"((uint16_t)
b), "r"((uint32_t)c), "r"((uint64_t)d));
}






always uses 8bit register for a, 16bit register for b, 32bit register for c,
64bit register for d.








Do you happen to know of any counter-example?








 
"

> 2) can I assume anything about the high-order bits of the register? can I

> overwrite them freely?

No; yes.

> 2a) does gcc use the "high" 8bit registers (ah, bh, ch, dh) for variable
> allocation?

No. "



Ok, thanks, another important information.


 
"

> 2b) can gcc allocate different 8bit variables in the "low" and "high" 
> registers (eg. al/ah, bl/bh, ...)?
>
>
> For variables of type:
>
> uint8_t a8, b8;
> uint16_t a16, b16;
> ...

I think not, but I'm unsure.
"



According to 2a), ah/bh/... are not used for register alocation -> so "No."



"
> Enforcing same-sized arguments:
> a)
> __asm__ ("movb %b1, %b0" : "=r"(a8) : "r"(b8));
> or
> __asm__ ("movq %q1, %q0" : "=r"(a8) : "r"(b8));
> is always safe to do? (eg. moving 56bits of garbage won't hurt anything)
> OR might gcc assume something about the high-order 56bits (eg. zero, sign-
/
> zero-extension of the lower 8 bits), which might get broken by the move?

If you ask for a register with the "r" constraint, all of that
register is yours to use.


> Assuming zero-extension:
> __asm__ ("movw %w1, %w0" : "=r"(a16) : "r"((uint8_t)b16));
> or
> __asm__ ("movw %w1, %w0" : "=r"(a16) : "r"(b8));
> does not seem to work (high-order 8 bits of a16 are garbage)

That's how x86 works.
"
 

Garbage in, garbage out. The high order bits are undefined.




"
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 "



Best regards,
Zdenek Sojka