inline asm: Behaviour on type mismatch for inputs

[notYuriy]

Compiler explorer link: https://zig.godbolt.org/z/KvG5h3
Zig code involved:

const std = @import("std");

pub fn main() !void {
    testcall(true);
    return;
}

export fn testcall(t: bool) void { 
    asm volatile("" : : [_] "{rbx}" (@as(u64,0x1122334455667788)) : "memory" ); // clobber rbx with garbage to not give it a chance
    asm volatile(
        \\push %%rbx
        \\pop  %%rdi
        \\call stage2
        :
        : [_] "{rbx}" (@boolToInt(t))
        : "memory"
    );

}

export fn stage2(param: usize) void {
    std.debug.warn("param: {x}", .{param});
}

What's the problem? Well, let's look at the code zig compiler from trunk gave us:

testcall:
        push    rbx
        movabs  rbx, 1234605616436508552; clobber rbx with garbage to not give it a chance 

        ; That's how rbx is assigned to 1
        and     dil, 1
        mov     ebx, edi 
        ; End of assignment

        push    rbx ; That is where our asm volatile code starts
        pop     rdi
        call    stage2
        pop     rbx
        ret

Zig compiler generates code that only makes the lowest bit of rbx set. The problem is that the code explicitly demands that the compiler generates code assigning one to the rbx, meaning that the value of rbx should be one, while if you run this example in compiler explorer, it will give you a different result.

Cast to u64 indeed solve the problem, however, this case is either 1) an incorrect behavior that should be patched 2) correct behavior that needs to be clarified (so that there is a requirement that code inside volatile asm block will only use rdi as u1, and not as usize as here)

[notYuriy]

Another example: https://zig.godbolt.org/z/KvG5h3

const std = @import("std");

pub fn main() !void {
    testcall();
    return;
}

export fn testcall() void { 
    asm volatile("" : : [_] "{rbx}" (@as(u64,0x1122334455667788)) : "memory", "{rbx}" ); // clobber rbx with garbage

    var boolean: bool = true;          // this is required to be u32 or u64, otherwise it will not clear the upper bits
    asm volatile("" : : [_] "{rbx}" (@boolToInt(boolean)) : "memory" );

    var bl:  u8  = asm ("" : [_] "={bl}" (-> u8) : : "{ebx}");
    // var bh:  u8  = asm ("" : [_] "={bh}" (-> u8) : : "{ebx}");
    var bx:  u16 = asm ("" : [_] "={bx}" (-> u16) : : "{ebx}");
    var ebx: u32 = asm ("" : [_] "={ebx}" (-> u32) : : "{ebx}");
    var rbx: u64 = asm ("" : [_] "={rbx}" (-> u64) : : "{ebx}");

    std.debug.print(
        \\bl={X} bh={X}
        \\bx={X}
        \\ebx={X}
        \\rbx={X}
        \\
        ,.{ bl, 0, bx, ebx, rbx });
}

(credit goes to @MasterQ32)
Generated assembly here is

testcall:
        push    rbp
        push    r15
        push    r14
        push    r12
        push    rbx
        sub     rsp, 144
        movabs  rbx, 1234605616436508552
        mov     bl, 1
        mov     r15d, ebx
        mov     r12d, ebx
        mov     r14d, ebx
        ; ...

Assignment to 1 is done by setting bl to 1. This is simply incorrect, you can see that in the debug output

bl=1 bh=0
bx=7701
ebx=55667701
rbx=1122334455667701

[LemonBoy]

That's intentional I guess.

[notYuriy]

That's intentional I guess.

@LemonBoy If that's intentional, it should be stated and emphasized in the language specification, as it's very different from what other programming languages usually do.

[ikskuh]

That's intentional I guess.

This code snippet does not address the problem that happens here. What @notYuriy wants to achieve is setting the register rbx by specifying it in the input description explicitly (by using {rbx} instead of just r or a or whatever), but LLVM then sets the register bl which behaves differently when set (it doesn't set the upper 56 bit of rbx)

[notYuriy]

@MasterQ32 I guess what @LemonBoy is trying to say is that it only updates the lowest bit of rbx on purpose. I have only passed u1, so it thinks that value will only be used as u1. This needs more clarification in the docs if that is the case.

[LemonBoy]

LLVM then sets

LLVM is doing what the Zig compiler is asking it to do. I've linked the place where the compiler decides what to do with the inline asm operands: the u1 is internally zero-extended to u8, hence the generated code you're seeing.

[ikskuh]

After a quick discussion on IRC:

Make this a proposal which proposes:

When a concrete register name is given (in this example rbx), either:

• (1) disallow setting a value that is not the same size (which would be u64 in this case) or
• (2) apply the usual coercion semantics (so the value in the parens will only accept u64 or i64 values and the expression automatically coerces into the right type)

Both variants remove the unexpected footgun that is happening here:

// this will not set the register `rbx`, but `bl` which means that after this line `rbx` will contain 0xUUUU_UUUU_UUUU_UU01
asm volatile("":: [_] "{rbx}" (@as(u1, 1)):); 

I'm personally in favour for option (2) as it will allow us passing in a value of type comptime_int and it will automatically coerce to the right type, allowing much simplified constant register initialization