Talk:X86 Assembly/GNU assembly syntax


 * comments from development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de

EBP is used as the base register to reference the local variables [1], and a value is subtracted from ESP to reserve space on the stack
 * I have the impression that does not make sense. Isn't ESP used as stack pointer and base register for the local variables whereas EBP is used as base pointer to the procedure arguments (which are pushed on the stack before calling the procedure). -- REGARDS -- development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de. I'm only passing through here, so if this point needs discussion, please notify me by mail.

Your GCC produces much different code (more, even) than mine does. Even for hello_world. Yours calls __alloc and ___main, mine doesn't.
 * Thats because These functions are part of the C library setup. Since we are calling functions in the C library, we probably need these isn't true. ___main facilitates C++ static initialisation on non-ELF system (ELF systems include UNIX/LINUX but not Windows). If you don't call C++ code, ___main isn't required. The comments about using Win32 API in place of the C standard library really should be re-visited in light of this.
 * No compiler will ever emit a call to "__alloca". Alloca is a compiler intrinsic that gets compiled to allocating stack frame space. 63.235.13.3 (discuss) 00:50, 1 July 2012 (UTC)

You write: ''In this case, eight bytes have been reserved on the stack. Since we have no local variables in this procedure, this code is unnecessary.'' [2]


 * That's unfortunately not true. You should note, that later we have 'movl $LC0, (%esp)'. This is exactly where the temporary reserved at the beginning of the procedure becomes a necessity.


 * It's important to remember that the code output of the assembler will be very much dependant on the local environment. If the generated code is different from yours, it is likely the result of either a different version of the compiler, different libraries, or a different operating system. --Whiteknight (Page) (Talk) 19:11, 22 June 2007 (UTC)
 * absolutely right: That accounts for the different output of our respective compilers. But my other comments still stand: [1] seems to be a typo and [2] seems to be simply wrong. But don't take it on my authority (which has over the years become rather weak concerning gcc output), which is why I'm not changing it myself now: A second opinion would be nice. -- M.
 * I seem to think that [1] is correct, although it has been a long time for me since I've last used GCC to generate assembly as well. It is something that we should probably double-check before we make any changes. As for [2], you are right that it seems to be an error, so i've gone ahead and changed it. --Whiteknight (Page) (Talk) 23:45, 24 June 2007 (UTC)

then rewrite selected routines in assembly language (which performs better)
 * Kind of hard to take this page seriously if this is the advice, circa 2010. It's been demonstrated that in fact compilers do regularly produce better code than handcoded assembly does. In fact aggressive inlining from JITs in "slow" languages like Java can be faster than C!

Caveats
This happens with all the non-commutative arithmetic floating point operations with two register operands where the source register is %st and the destination register is %st(i). What does this mean? Addition and multiplication are both perfectly commutative.

... subtraction is not --box