3 ms·

C is generally first compiled into assembly anyways. When you program in assembly you're basically just doing the job of the compiler, and can call all the sam

C is generally first compiled into assembly anyways. When you program in assembly you're basically just doing the job of the compiler, and can call all the same library functions C code can. You just have to follow the calling conventions of the architecture. It's cumbersome and tedious, but nowhere near impossible. x64 made calling functions more annoying by using registers then spilling over into the stack after exhausting those. x32 was more pleasant by far, since it only used the stack. x64's convention produces faster code though, by keeping stuff in registers.

nineteen999 3y ago
> x32 was more pleasant by far, since it only used the stack Maybe I misunderstand you, but this is completely dependent on compiler, operating system etc, there are multiple calling conventions for x86-32, eg. cdecl, fastcall ... https://en.wikipedia.org/wiki/X86_calling_conventions https://en.wikipedia.org/wiki/X86_calling_conventions
- pengaru 3y ago
  Apologies, my experience is SysV-centric for amd64, as described here[0] under the Parameter Passing section, which is a clustrfuck compared to the simplicity of the 386 SysV ABI as described here[1]: > Argument words are pushed onto the stack in reverse order (that is, the > rightmost argument in C call syntax has the highest address), preserving the > stack’s word alignment. All incoming arguments appear on the stack, resid- > ing in the stack frame of the caller. Both links were found @ https://wiki.osdev.org/System_V_ABI https://wiki.osdev.org/System_V_ABI [0] https://www.uclibc.org/docs/psABI-x86_64.pdf https://www.uclibc.org/docs/psABI-x86_64.pdf [1] https://www.sco.com/developers/devspecs/abi386-4.pdf https://www.sco.com/developers/devspecs/abi386-4.pdf
kristianp 3y ago
> C is generally first compiled into assembly anyways. I don't think that's right. C is compiled into an intermediate representation first. It's true that you can ask GCC etc. to generate assembly output, but it's not the default.
- pengaru 3y ago
  > I don't think that's right. C is compiled into an intermediate representation first. It's true that you can ask GCC etc. to generate assembly output, but it's not the default. Just because there's an IR within the compiler doesn't mean there's no "assemble" stage. What do you think the "-pipe" flag to gcc is for? It pipes the compiler output into the assembler, rather than using a temporary .s file. gcc has four main stages going from source to executable: preprocessor->compiler->assembler->linker. Edit, for your convenience, gcc -save-temps example: > [user@host /tmp/foo]$ ls > f.c > [user@host /tmp/foo]$ cat f.c > #include <stdio.h> > > int main(int argc, char **argv) > { > puts("Hello world!"); > > return 0; > } > [user@host /tmp/foo]$ gcc -o f -save-temps f.c > [user@host /tmp/foo]$ ls -l > total 48 > -rwxr-xr-x 1 user user 15416 Jan 13 16:50 f > -rw-r--r-- 1 user user 91 Jan 13 16:49 f.c > -rw-r--r-- 1 user user 17145 Jan 13 16:50 f.i > -rw-r--r-- 1 user user 1496 Jan 13 16:50 f.o > -rw-r--r-- 1 user user 515 Jan 13 16:50 f.s > [user@host /tmp/foo]$ cat f.s > .file "f.c" > .text > .section .rodata > .LC0: > .string "Hello world!" > .text > .globl main > .type main, @function > main: > .LFB0: > .cfi_startproc > pushq %rbp > .cfi_def_cfa_offset 16 > .cfi_offset 6, -16 > movq %rsp, %rbp > .cfi_def_cfa_register 6 > subq $16, %rsp > movl %edi, -4(%rbp) > movq %rsi, -16(%rbp) > leaq .LC0(%rip), %rax > movq %rax, %rdi > call puts@PLT > movl $0, %eax > leave > .cfi_def_cfa 7, 8 > ret > .cfi_endproc > .LFE0: > .size main, .-main > .ident "GCC: (GNU) 13.1.1 20230429" > .section .note.GNU-stack,"",@progbits > [user@host /tmp/foo]$ ./f > Hello world! > [user@host /tmp/foo]$ >
  - kristianp 3y ago
    Thanks for the correction, I assumed the assembly stage was not done.
- kragen 3y ago
  there are compilers that do not generate textual assembly output from their ir, but gcc in particular does
kragen 3y ago
i suspect you mean i386, not x32; x32 is an almost unused abi added in 02011 for 64-bit amd and compatible processors, available with gcc -mx32. https://lwn.net/Articles/548838/ https://lwn.net/Articles/548838/ talks a bit about its early adoption it's so little used that i can't find the abi documentation, but gcc -c -mx32 does seem to generate code that passes arguments in registers, not on the stack, contrary to your assertion edit: after enough digging, i found https://web.archive.org/web/20130902094821/https://sites.google.com/site/x32abi/documents https://web.archive.org/web/20130902094821/https://sites.goo... linking to https://web.archive.org/web/20201015005434/https://3263a7b2-a-62cb3a1a-s-sites.googlegroups.com/site/x32abi/documents/ifunc.txt?attachauth=ANoY7cr6lpyjuRyT4rmzHQ8Yrzbm0zw6mrWdX5nYk2SA-3HpzQhMfB6w3bnY-y00KmSbZv0nFfZ26ntH4PlotgL6bNiot5isYETkx2Ob_R7965vMKJ3Frib80DkVIrTPvk5_koGv_HIYJiMOwVMWP1AvwmXnT6-PlLM5pKoJ4trQelEVMmoHXExz5mvkz5H9RHfeFf0339K8PL-VUnWc_flglK9vJifV3w%3D%3D&attredirects=0&d=1 https://web.archive.org/web/20201015005434/https://3263a7b2-... but x32-abi-1.0.pdf seems to be missing from the archive and https://web.archive.org/web/*/https://sites.google.com/site/x32abi/documents/ https://web.archive.org/web/*/https://sites.google.com/site/...* doesn't look at all promising
- pengaru 3y ago
  You're right, I was sloppy in typing x32 for i386 (as you mentioned, nobody actually uses that).
  - kragen 3y ago
    cool, thanks for clarifying
quesera 3y ago
> C is generally first compiled into assembly anyways. Splitting hairs perhaps, but the C compiler output is machine code, right? No reason to generate assembly along the way.
- pengaru 3y ago
  > > C is generally first compiled into assembly anyways. > Splitting hairs > > generally smh https://en.wikipedia.org/wiki/Compiler#Three-stage_compiler_structure https://en.wikipedia.org/wiki/Compiler#Three-stage_compiler_...

nineteen999 3y ago

> x32 was more pleasant by far, since it only used the stack Maybe I misunderstand you, but this is completely dependent on compiler, operating system etc, there are multiple calling conventions for x86-32, eg. cdecl, fastcall ... https://en.wikipedia.org/wiki/X86_calling_conventions https://en.wikipedia.org/wiki/X86_calling_conventions

pengaru 3y ago
Apologies, my experience is SysV-centric for amd64, as described here[0] under the Parameter Passing section, which is a clustrfuck compared to the simplicity of the 386 SysV ABI as described here[1]: > Argument words are pushed onto the stack in reverse order (that is, the > rightmost argument in C call syntax has the highest address), preserving the > stack’s word alignment. All incoming arguments appear on the stack, resid- > ing in the stack frame of the caller. Both links were found @ https://wiki.osdev.org/System_V_ABI https://wiki.osdev.org/System_V_ABI [0] https://www.uclibc.org/docs/psABI-x86_64.pdf https://www.uclibc.org/docs/psABI-x86_64.pdf [1] https://www.sco.com/developers/devspecs/abi386-4.pdf https://www.sco.com/developers/devspecs/abi386-4.pdf

kristianp 3y ago

> C is generally first compiled into assembly anyways. I don't think that's right. C is compiled into an intermediate representation first. It's true that you can ask GCC etc. to generate assembly output, but it's not the default.

pengaru 3y ago
> I don't think that's right. C is compiled into an intermediate representation first. It's true that you can ask GCC etc. to generate assembly output, but it's not the default. Just because there's an IR within the compiler doesn't mean there's no "assemble" stage. What do you think the "-pipe" flag to gcc is for? It pipes the compiler output into the assembler, rather than using a temporary .s file. gcc has four main stages going from source to executable: preprocessor->compiler->assembler->linker. Edit, for your convenience, gcc -save-temps example: > [user@host /tmp/foo]$ ls > f.c > [user@host /tmp/foo]$ cat f.c > #include <stdio.h> > > int main(int argc, char **argv) > { > puts("Hello world!"); > > return 0; > } > [user@host /tmp/foo]$ gcc -o f -save-temps f.c > [user@host /tmp/foo]$ ls -l > total 48 > -rwxr-xr-x 1 user user 15416 Jan 13 16:50 f > -rw-r--r-- 1 user user 91 Jan 13 16:49 f.c > -rw-r--r-- 1 user user 17145 Jan 13 16:50 f.i > -rw-r--r-- 1 user user 1496 Jan 13 16:50 f.o > -rw-r--r-- 1 user user 515 Jan 13 16:50 f.s > [user@host /tmp/foo]$ cat f.s > .file "f.c" > .text > .section .rodata > .LC0: > .string "Hello world!" > .text > .globl main > .type main, @function > main: > .LFB0: > .cfi_startproc > pushq %rbp > .cfi_def_cfa_offset 16 > .cfi_offset 6, -16 > movq %rsp, %rbp > .cfi_def_cfa_register 6 > subq $16, %rsp > movl %edi, -4(%rbp) > movq %rsi, -16(%rbp) > leaq .LC0(%rip), %rax > movq %rax, %rdi > call puts@PLT > movl $0, %eax > leave > .cfi_def_cfa 7, 8 > ret > .cfi_endproc > .LFE0: > .size main, .-main > .ident "GCC: (GNU) 13.1.1 20230429" > .section .note.GNU-stack,"",@progbits > [user@host /tmp/foo]$ ./f > Hello world! > [user@host /tmp/foo]$ >
- kristianp 3y ago
  Thanks for the correction, I assumed the assembly stage was not done.
kragen 3y ago
there are compilers that do not generate textual assembly output from their ir, but gcc in particular does

kragen 3y ago

i suspect you mean i386, not x32; x32 is an almost unused abi added in 02011 for 64-bit amd and compatible processors, available with gcc -mx32. https://lwn.net/Articles/548838/ https://lwn.net/Articles/548838/ talks a bit about its early adoption it's so little used that i can't find the abi documentation, but gcc -c -mx32 does seem to generate code that passes arguments in registers, not on the stack, contrary to your assertion edit: after enough digging, i found https://web.archive.org/web/20130902094821/https://sites.google.com/site/x32abi/documents https://web.archive.org/web/20130902094821/https://sites.goo... linking to https://web.archive.org/web/20201015005434/https://3263a7b2-a-62cb3a1a-s-sites.googlegroups.com/site/x32abi/documents/ifunc.txt?attachauth=ANoY7cr6lpyjuRyT4rmzHQ8Yrzbm0zw6mrWdX5nYk2SA-3HpzQhMfB6w3bnY-y00KmSbZv0nFfZ26ntH4PlotgL6bNiot5isYETkx2Ob_R7965vMKJ3Frib80DkVIrTPvk5_koGv_HIYJiMOwVMWP1AvwmXnT6-PlLM5pKoJ4trQelEVMmoHXExz5mvkz5H9RHfeFf0339K8PL-VUnWc_flglK9vJifV3w%3D%3D&attredirects=0&d=1 https://web.archive.org/web/20201015005434/https://3263a7b2-... but x32-abi-1.0.pdf seems to be missing from the archive and https://web.archive.org/web/*/https://sites.google.com/site/x32abi/documents/ https://web.archive.org/web/*/https://sites.google.com/site/...* doesn't look at all promising

pengaru 3y ago
You're right, I was sloppy in typing x32 for i386 (as you mentioned, nobody actually uses that).
- kragen 3y ago
  cool, thanks for clarifying

quesera 3y ago

> C is generally first compiled into assembly anyways. Splitting hairs perhaps, but the C compiler output is machine code, right? No reason to generate assembly along the way.

pengaru 3y ago
> > C is generally first compiled into assembly anyways. > Splitting hairs > > generally smh https://en.wikipedia.org/wiki/Compiler#Three-stage_compiler_structure https://en.wikipedia.org/wiki/Compiler#Three-stage_compiler_...