Proposal: Eliminate global assembly from the language

[alexrp]

Proposal

Global assembly basically requires implementing an actual assembler for its typical use cases, with all the legacy cruft that that implies: Many directives that do the same thing, directives that work in highly unintuitive ways (e.g. .symver), a macro system (.macro), silently overwriting symbol properties, etc.

A full assembler also has undesirable effects on the compilation pipeline because of the ability to introduce and change symbols arbitrarily, as well as the ability to switch between arbitrary sections while assembling.

We plan to implement an assembler anyway (#21169), but it's intended to be a separate tool for compiling existing assembly source files rather than one that you can invoke in the language through global assembly. For inline assembly, the plan is to have a more 'Zig-native' syntax (#10761).

Putting all of those factors together, global assembly doesn't seem worth keeping in the language.

Any use cases that are currently served by global assembly should then be served by proper language features instead, such as in #24076. If you're currently relying on global assembly, please comment with details on your use case.

cc #24046

[top-master]

"please comment with details on your use case"

What if an entire function is written in ASM, rather than just an inline portion?

I'm new to Zig, however, if that use-case is possible with Zig, then
that's a feature that I would like to remaing in Zig, because managing external .s files may complicate things.

EDIT: said use-case is possible with Zig, as the docs mention:

const std = @import("std");
const expect = std.testing.expect;

comptime {
    asm (
        \\.global my_func;
        \\.type my_func, @function;
        \\my_func:
        \\  lea (%rdi,%rsi,1),%eax
        \\  retq
    );
}

extern fn my_func(a: i32, b: i32) i32;

test "global assembly" {
    try expect(my_func(12, 34) == 46);
}

[alexrp]

What if an entire function is written in ASM, rather than just an inline portion?

What is the use case for this? Is it one that would not be satisfied by naked functions, which Zig already has?

[top-master]

Can you give an example of that, I mean, is that ASM as well?

[alexrp]

zig/lib/std/start.zig

Lines 239 to 485 in e96d860

	fn _start() callconv(.naked) noreturn {
	// TODO set Top of Stack on non x86_64-plan9
	if (native_os == .plan9 and native_arch == .x86_64) {
	// from /sys/src/libc/amd64/main9.s
	std.os.plan9.tos = asm volatile (""
	: [tos] "={rax}" (-> *std.os.plan9.Tos),
	);
	}
	// This is the first userspace frame. Prevent DWARF-based unwinders from unwinding further. We
	// prevent FP-based unwinders from unwinding further by zeroing the register below.
	if (builtin.unwind_tables != .none or !builtin.strip_debug_info) asm volatile (switch (native_arch) {
	.arc => ".cfi_undefined blink",
	.arm, .armeb, .thumb, .thumbeb => "", // https://github.com/llvm/llvm-project/issues/115891
	.aarch64, .aarch64_be => ".cfi_undefined lr",
	.csky => ".cfi_undefined lr",
	.hexagon => ".cfi_undefined r31",
	.loongarch32, .loongarch64 => ".cfi_undefined 1",
	.m68k => ".cfi_undefined %%pc",
	.mips, .mipsel, .mips64, .mips64el => ".cfi_undefined $ra",
	.powerpc, .powerpcle, .powerpc64, .powerpc64le => ".cfi_undefined lr",
	.riscv32, .riscv64 => if (builtin.zig_backend == .stage2_riscv64)
	""
	else
	".cfi_undefined ra",
	.s390x => ".cfi_undefined %%r14",
	.sparc, .sparc64 => ".cfi_undefined %%i7",
	.x86 => ".cfi_undefined %%eip",
	.x86_64 => ".cfi_undefined %%rip",
	else => @compileError("unsupported arch"),
	});
	// Move this to the riscv prong below when this is resolved: https://github.com/ziglang/zig/issues/20918
	if (builtin.cpu.arch.isRISCV() and builtin.zig_backend != .stage2_riscv64) asm volatile (
	\\ .weak __global_pointer$
	\\ .hidden __global_pointer$
	\\ .option push
	\\ .option norelax
	\\ lla gp, __global_pointer$
	\\ .option pop
	);
	// Note that we maintain a very low level of trust with regards to ABI guarantees at this point.
	// We will redundantly align the stack, clear the link register, etc. While e.g. the Linux
	// kernel is usually good about upholding the ABI guarantees, the same cannot be said of dynamic
	// linkers; musl's ldso, for example, opts to not align the stack when invoking the dynamic
	// linker explicitly.
	asm volatile (switch (native_arch) {
	.x86_64 =>
	\\ xorl %%ebp, %%ebp
	\\ movq %%rsp, %%rdi
	\\ andq $-16, %%rsp
	\\ callq %[posixCallMainAndExit:P]
	,
	.x86 =>
	\\ xorl %%ebp, %%ebp
	\\ movl %%esp, %%eax
	\\ andl $-16, %%esp
	\\ subl $12, %%esp
	\\ pushl %%eax
	\\ calll %[posixCallMainAndExit:P]
	,
	.aarch64, .aarch64_be =>
	\\ mov fp, #0
	\\ mov lr, #0
	\\ mov x0, sp
	\\ and sp, x0, #-16
	\\ b %[posixCallMainAndExit]
	,
	.arc =>
	// The `arc` tag currently means ARC v1 and v2, which have an unusually low stack
	// alignment requirement. ARC v3 increases it from 4 to 16, but we don't support v3 yet.
	\\ mov fp, 0
	\\ mov blink, 0
	\\ mov r0, sp
	\\ and sp, sp, -4
	\\ b %[posixCallMainAndExit]
	,
	.arm, .armeb, .thumb, .thumbeb =>
	// Note that this code must work for Thumb-1.
	// r7 = FP (local), r11 = FP (unwind)
	\\ movs v1, #0
	\\ mov r7, v1
	\\ mov r11, v1
	\\ mov lr, v1
	\\ mov a1, sp
	\\ subs v1, #16
	\\ ands v1, a1
	\\ mov sp, v1
	\\ b %[posixCallMainAndExit]
	,
	.csky =>
	// The CSKY ABI assumes that `gb` is set to the address of the GOT in order for
	// position-independent code to work. We depend on this in `std.pie` to locate
	// `_DYNAMIC` as well.
	// r8 = FP
	\\ grs t0, 1f
	\\ 1:
	\\ lrw gb, 1b@GOTPC
	\\ addu gb, t0
	\\ movi r8, 0
	\\ movi lr, 0
	\\ mov a0, sp
	\\ andi sp, sp, -8
	\\ jmpi %[posixCallMainAndExit]
	,
	.hexagon =>
	// r29 = SP, r30 = FP, r31 = LR
	\\ r30 = #0
	\\ r31 = #0
	\\ r0 = r29
	\\ r29 = and(r29, #-8)
	\\ memw(r29 + #-8) = r29
	\\ r29 = add(r29, #-8)
	\\ call %[posixCallMainAndExit]
	,
	.loongarch32, .loongarch64 =>
	\\ move $fp, $zero
	\\ move $ra, $zero
	\\ move $a0, $sp
	\\ bstrins.d $sp, $zero, 3, 0
	\\ b %[posixCallMainAndExit]
	,
	.riscv32, .riscv64 =>
	\\ li fp, 0
	\\ li ra, 0
	\\ mv a0, sp
	\\ andi sp, sp, -16
	\\ tail %[posixCallMainAndExit]@plt
	,
	.m68k =>
	// Note that the - 8 is needed because pc in the jsr instruction points into the middle
	// of the jsr instruction. (The lea is 6 bytes, the jsr is 4 bytes.)
	\\ suba.l %%fp, %%fp
	\\ move.l %%sp, %%a0
	\\ move.l %%a0, %%d0
	\\ and.l #-4, %%d0
	\\ move.l %%d0, %%sp
	\\ move.l %%a0, -(%%sp)
	\\ lea %[posixCallMainAndExit] - . - 8, %%a0
	\\ jsr (%%pc, %%a0)
	,
	.mips, .mipsel =>
	\\ move $fp, $0
	\\ bal 1f
	\\ .gpword .
	\\ .gpword %[posixCallMainAndExit]
	\\ 1:
	// The `gp` register on MIPS serves a similar purpose to `r2` (ToC pointer) on PPC64.
	\\ lw $gp, 0($ra)
	\\ subu $gp, $ra, $gp
	\\ lw $25, 4($ra)
	\\ addu $25, $25, $gp
	\\ move $ra, $0
	\\ move $a0, $sp
	\\ and $sp, -8
	\\ subu $sp, $sp, 16
	\\ jalr $25
	,
	.mips64, .mips64el =>
	\\ move $fp, $0
	// This is needed because early MIPS versions don't support misaligned loads. Without
	// this directive, the hidden `nop` inserted to fill the delay slot after `bal` would
	// cause the two doublewords to be aligned to 4 bytes instead of 8.
	\\ .balign 8
	\\ bal 1f
	\\ .gpdword .
	\\ .gpdword %[posixCallMainAndExit]
	\\ 1:
	// The `gp` register on MIPS serves a similar purpose to `r2` (ToC pointer) on PPC64.
	\\ ld $gp, 0($ra)
	\\ dsubu $gp, $ra, $gp
	\\ ld $25, 8($ra)
	\\ daddu $25, $25, $gp
	\\ move $ra, $0
	\\ move $a0, $sp
	\\ and $sp, -16
	\\ dsubu $sp, $sp, 16
	\\ jalr $25
	,
	.powerpc, .powerpcle =>
	// Set up the initial stack frame, and clear the back chain pointer.
	// r1 = SP, r31 = FP
	\\ mr 3, 1
	\\ clrrwi 1, 1, 4
	\\ li 0, 0
	\\ stwu 1, -16(1)
	\\ stw 0, 0(1)
	\\ li 31, 0
	\\ mtlr 0
	\\ b %[posixCallMainAndExit]
	,
	.powerpc64, .powerpc64le =>
	// Set up the ToC and initial stack frame, and clear the back chain pointer.
	// r1 = SP, r2 = ToC, r31 = FP
	\\ addis 2, 12, .TOC. - %[_start]@ha
	\\ addi 2, 2, .TOC. - %[_start]@l
	\\ mr 3, 1
	\\ clrrdi 1, 1, 4
	\\ li 0, 0
	\\ stdu 0, -32(1)
	\\ li 31, 0
	\\ mtlr 0
	\\ b %[posixCallMainAndExit]
	\\ nop
	,
	.s390x =>
	// Set up the stack frame (register save area and cleared back-chain slot).
	// r11 = FP, r14 = LR, r15 = SP
	\\ lghi %%r11, 0
	\\ lghi %%r14, 0
	\\ lgr %%r2, %%r15
	\\ lghi %%r0, -16
	\\ ngr %%r15, %%r0
	\\ aghi %%r15, -160
	\\ lghi %%r0, 0
	\\ stg %%r0, 0(%%r15)
	\\ jg %[posixCallMainAndExit]
	,
	.sparc =>
	// argc is stored after a register window (16 registers * 4 bytes).
	// i7 = LR
	\\ mov %%g0, %%fp
	\\ mov %%g0, %%i7
	\\ add %%sp, 64, %%o0
	\\ and %%sp, -8, %%sp
	\\ ba,a %[posixCallMainAndExit]
	,
	.sparc64 =>
	// argc is stored after a register window (16 registers * 8 bytes) plus the stack bias
	// (2047 bytes).
	// i7 = LR
	\\ mov %%g0, %%fp
	\\ mov %%g0, %%i7
	\\ add %%sp, 2175, %%o0
	\\ add %%sp, 2047, %%sp
	\\ and %%sp, -16, %%sp
	\\ sub %%sp, 2047, %%sp
	\\ ba,a %[posixCallMainAndExit]
	,
	else => @compileError("unsupported arch"),
	}
	:
	: [_start] "X" (&_start),
	[posixCallMainAndExit] "X" (&posixCallMainAndExit),
	);
	}

[top-master]

There're no arguments hence I can't really compare; how would my_asm_add_numbers look like in such naked Zig?

[alexrp]

It's roughly analogous to __attribute__((naked)). You access the arguments in the assembly code just as you would in a C function declared that way.

[top-master]

Basically, something like:

fn my_asm_add_numbers(aArg: i32, bArg: i32) i32 callconv(.naked) {
    asm volatile (
        \\ lea (%rdi, %rsi), %eax // aArg + bArg
        \\ ret
    )
}

In that case said use-case is already supported in an even better way.

Edit: Of course, we could pass control instantly to inline asm to simulate asm-functions like above, however, if said .s file has multiple methods then the rewrite takes too much time.

[andrewrk]

There are several use cases that people have mentioned in chat rooms that would go unsolved should they no longer have the ability to do comptime logic + assembly string manipulation.

This issue is still accepted, but let's try to get those use cases enumerated here clearly so that we can offer a smooth upgrade path before proceeding.