Well.... ok, here is the deal. The machine code is portable across operating systems since it is just the way the CPU operates commands. However, the machine code that runs on a MIPS processor is vastly different than that which runs on a 8088. However, executable files are different across different files. They embed different information within headers and the body of an executable. The sections that contain machine code are going to be the only similarity. So again, no. Assembler is just about the least portable langauge you can use.
Assembler and machine code have a 1:1 relationship. One instruction [as long as we stay with one processor architecture, e.g. X86] will produce one set of instruction bytes. There are some instructions that have synonyms (that is, there are more than one way to form a valid instruction that does this thing), but the output from the assembler will have the exact same meaning for either of those synonyms - it may be a byte or two longer, but other than that, it's the same result.
Originally Posted by lruc
Sure, NASM, MASM and CPP + GAS have slightly differnet syntax for Macros and other pseudo-operations [pseudo-ops are things that aren't actual machine-code instructions, but rather instructions to the assembler as to what you want done, where you want it [e.g. .data, .code are instrucitons to the assembler that "what comes next should go in the data section or the code section].
Also, if you use gas on windows, the code will work on Windows, and as long as you don't call the OS, you can assemble the same thing in Linux and get the same result.
There is absolutely no meaning in remembering that 8B is MOV, 75 is JNZ, 90 is NOP, EA is a JMP, CC is INT3, etc. [But if you want to check those out, I think I got most of them about right]. That is of course x86. On 68000 the instructions have somewhat differnet names, and completely different opcodes.
The following code should assemble, and make an executable file that works, for both Linux and Windows:
mov $hello, %eax
add $4, %esp
xor %eax, %eax
hello: .string "Hello, World!\n"
as -o asm.o asm.s
gcc -o asm.exe asm.o
I think the more important issue he is somewhat not fully comprehending is that even though the opcodes are going to remain the same outside of operating system constraint, the underlying hardware is one thing that you cannot necessarily count on. Unless you are programming for something that doesn't allow any sort of variation on the underlying hardware. Such as a gaming console or DVR or something like that.
So it's like your portable among hardware, or your portable among operating systems, but without a portable library you can't be portable among both. Am I getting this strait?
Also, matsp. Your code will not assemble correctly. I keep on getting an error message stating entry point _start can't be found and that _puts is an undefined reference. Any help?
Change _main: to _start: and link to the c standard library....
That sounds dangerous. gcc uses the entry symbol _start to call initialization, and initializing glibc is part of that, I think. Shouldn't you keep using main, but link in GCC's startup files?