integrated assembly and intel/NASM syntax for x86 assembly

[andrewrk]

Extracted from #215 (comment).

Currently Zig relies on LLVM for assembly parsing on all targets.

It's a big project if Zig were to take on knowledge of the assembly format of every supported target, but if we were to do that, it would bring some benefits:

• Intel/NASM syntax for x86 which is generally preferable to AT&T syntax which we are currently stuck with due to LLVM's Intel syntax support being untested and buggy.

• Ability for tighter integration with Zig code that could do things such as automatically determining clobbers.

• Maybe it's not so bad to reduce dependency on LLVM. This would bring us closer to a fully self hosted toolchain and make it possible to experiment with bypassing LLVM in debug mode for faster builds.

So I think this proposal is at least worth considering. There will have to be a decision before releasing 1.0.0.

[daurnimator]

From 15c316b#r32851500 :

We should specify an assembly syntax annotation/choice/argument to allow the choice of assembly syntax layer on.
e.g.

    return asm volatile (builtin.asmSyntax.att, "syscall"
        : [ret] "={rax}" (-> usize)
        : [number] "{rax}" (number),
          [arg1] "{rdi}" (arg1)
        : "rcx", "r11"
    );

[andrewrk]

I don't think Zig will acknowledge multiple assembly syntaxes. But you can do this in your assembly:

.intel_syntax noprefix

Again, I recommend against this due to the reasons mentioned above.

[shawnl]

New instructions are being added all the time to architectures, which makes an assembler a very high maintenance piece of software. This maintenance burden isn't as big of a deal when the hardware developers add support to llvm and gcc before they release their hardware, but it is unrealistic to expect them to add support to other tool-chains.

Wouldn't it be easier just to fix llvm's Intel syntax?

[ghost]

We'll need our own assemblers anyway, if we want a libc-less system interface with LLVM-less builds; so, making our own improvements is effectively zero-cost. I say it would be wise not to stray too far from GCC/LLVM, for compatibility, but we can make a few small changes:

• Intel syntax for x86/64 by default, but directives start with . and labels have :
• scas-style local labels (directives must start a line and not have a colon -- no ambiguity)
• In a similar vein, local constants, if we like
• No .common or .global -- symbol resolution hell
• .pub, .use for sharing symbols within a compilation unit
• .export, .extern for sharing symbols between objects (optional: .extern takes a module name, as in Zig)
• Repurpose .end to delimit symbols: .end sym == .size sym, (. - sym); cannot have both .end and .size
• Cull some redundant/historical symbols, possibly?

We may also consider some niceties:

• Declare a symbol as .pub or .export it inline: .pub main:, .export entry:
• Prefix or replace a symbol with its loader address: 0x8000_0000 label: or 0x8000_0000: (only possible where all previous symbols have been .ended)
• On the Zig side, @use(comptime T: type, comptime symbol: []const u8) T to access .pub symbols from assembly files; requires RFC: Make function definitions expressions #1717 to work properly (I considered an @sImport analogous to @cImport, but it would have been a royal pain typing everything properly, and the lack of explicit file dependencies (which we absolutely should not add -- I tried with Vertex, it was just too much) means assembly building will need to be coordinated by build.zig anyway)

[ghost]

^^^