views:

77

answers:

5

The assembly code generated by assembler, from a C-source code depends on the CPU architecture underlying it, eg x-86 .

Then does the assembler output of a simple C-source code (containing common function-calls of both windows and linux) differ between Operating Systems ?

+1  A: 

Assembly code may not vary between platforms that have identical machine opcodes, however it does vary between assemblers. gas (the GNU Assembler) output should be assemblable under any platform that supports it, but may not compile under nasm (the Netwide assembler).

zneak
hmmmm... a CPU is a CPU and assembling human readable instructions to machine-readable code doesn't change that.
jldupont
+2  A: 

It's a difficult question to answer. If I compile the following code:

void f() {
  int x = 0;
  x = x + 1;
}

to a .o file (i.e. not linked) on both platforms, would I exepect the x86 output to be the same?

Answer: Possibly. But I wouldn't be suprised if it wasn't.

anon
+1: that would be my take also.
jldupont
+2  A: 

The assembler really depends on the underlying architecture, rather than the operating system itself. So the generated code from an assemble should be the same across OSs.

However, there are some few conveats:

  1. OSs usually have different calling conventions that might get exposed to userland applications. This manifests itself in the assembly though, so the assembly itself might need to be different.

  2. The OSs would have different conventions for linking as well (e.g. static linking vs dynamic linking, etc). So the final executable might be different.

  3. Just because the generated files are the same, it doesn't mean that the resulting object files are portable. For system calls, the interrupt handler id differs among OSs. So if you hardcode the interrupt required for a system call in ASM, that code might not run in different OSs.

notnoop
the question here is focussed on C and compilation level details. The assembly process is basically just a "pass through to machine code with preprocessor help for human eyes".
jldupont
@jldupont, yes. I answered the question for the actual assembler, not the compiler. Oh well..
notnoop
A: 

If you use different compilers, different versions of the same compiler, or different flags for the compiler, all bets are off. Expect different assembly code. If you are assembling an actual .asm file, then the generated code should be identical, but will be packaged into an executable differently. Calling functions in shared objects or DLLs will obviously depend on what OS is used.

Joe
A: 

The output is going to vary from compiler to compiler, including from one gcc version to another from one gcc on one distro to another, or on the same machine. Basically the answer is yes, the output can and will vary widely. Saying that you may not find the difference at first depending on the code and depending on your compiler options, but the more different machines you try, 32 bit machines and 64 bit, subtle update differences in the same distro, etc. A common misunderstanding is that the C source code is the end of it, the program is done, performance is complete, etc. The reality is there are significant number of variations left going from C to binary even on the same machine with the same compiler, each variation has features and problems, debuggable or not, performance or not, bugs from the compiler or not. with a big enough program it is easy to demonstrate several times performance increase by using different switches on the compiler or using a better compiler. It does not matter if you are compiling to asm or an object (which depending on the compiler can and will stop at a temporary asm file that is assembled and then the intermediate files discarded), the order and choice of instructions will vary. Even a somewhat simple program try with or without the debug stuff (-g I think it is, I NEVER use it), and the various optimization levels -O0, -O1, -O2, -O3. 8 combinations right there, you should get a few different results, particularly from no optimization to some optimization.

dwelch