x86: printing of 8-bit immediate values

[vbgl]

The pretty-printing to x86 asm is not compatible with recent assemblers.

Here is an example program:

export
fn test(reg u64 p) -> reg u128 {
  reg u128 r;
  r = #AESKEYGENASSIST((u128)[p], 128);
  return r;
}

It is translated to the following assembly listing (AT&T syntax):

        .att_syntax
        .text
        .p2align        5
        .globl  _test
        .globl  test
_test:
test:
        aeskeygenassist $-128, (%rdi), %xmm0
        ret

for completeness, here it is in Intel syntax:

        .intel_syntax noprefix
        .text
        .p2align        5
        .globl  _test
        .globl  test
_test:
test:
        aeskeygenassist xmm0, xmmword ptr[rdi], -128
        ret

These assembly listings are accepted by GNU binutils 2.40, but at version 2.41, the following error arises:

….s:8: Error: operand type mismatch for `aeskeygenassist'

[eponier]

@sarranz If I remember correctly, you have experienced this bug already. Can you explain again what the problem is?

[sarranz]

I did. It looks like binutils no longer accepts some immediates. It's not so clear which or when, however. I could find
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=c34d1cc9200ae24dc7572aaf77d80276c0490e9b

[eponier]

The commit message is meaningful. Maybe this means that, as they seem to do, we should have two constructors Imm and ImmS to print unsigned or signed.

[vbgl]

This change fixes the test-suite, but might wrong:

--- a/compiler/src/ppasm.ml
+++ b/compiler/src/ppasm.ml
@@ -373,7 +373,7 @@ module Printer (BP:BPrinter) = struct
   let pp_asm_arg ((ws,op):(W.wsize * (_, _, _, _, _) Arch_decl.asm_arg)) =
     match op with
     | Condt  _   -> assert false
-    | Imm(ws, w) -> pp_imm (Conv.z_of_word ws w)
+    | Imm(ws, w) -> pp_imm ((if ws = U8 then Conv.z_unsigned_of_word else Conv.z_of_word) ws w)
     | Reg r      -> pp_register ~reg_pre (rsize_of_wsize ws) r
     | Regx r     -> pp_register_ext ~reg_pre ws r
     | Addr addr  -> BP.pp_address ws addr

[sarranz]

I understand that gas only does this when it doesn't make sense to have a negative value there

For shifts (but not ordinary rotates) and other cases where an immediate
describes e.g. a bit count or position, allowing negative operands is at
best confusing.

I don't understand why they do only for 8bit immediates --- I guess bigger immediates always go in places where it makes sense for them to be negative.
Probably we can print everything in hexadecimal and have it work, is readability of the assembly output the only reason we are making these distinctions? How important is it? (I'm not suggesting anything, just asking)

[vbgl]

Using hexadecimal notation does not seem to help, does it?

[sarranz]

I thought it would:
gas v2.38 accepts the code above https://godbolt.org/z/8vYjqojsd
writing the number in hexadecimal makes gas v4.1 accept it and produce the same output https://godbolt.org/z/qhW5hexK5

Do you have an example where it doesn't?

[vbgl]

The difference you observe in the examples above is not related to the base in which the number 2⁸ is written: in the first example, there is a minus sign that has been dropped in the second.