-2

I've been programming on assembly for microprocessors for some time and I'd like to jump into PC OS's. I'm confused with two OS running under the same architecture having different assembly codes for same programs. Isn't instruction set the same.

I'm for sure confusing concepts.

Could somebody shed some light on it?

Thanks

  • 2
    Instruction set is the same, calling conventions, system calls and other OS specific details are not. Also depending on what you are looking at, you might have code intended for different assemblers with differing syntax. – Jester Jul 05 '21 at 20:51
  • 1
    This also depends on the compiler used to convert the program from a high-level language to assembly. Even for the *same* OS, two compilers like e.g. gcc and clang will generate different code. The *same* compiler will generate different code depending on compiler options selected. – EOF Jul 05 '21 at 20:54
  • 1
    Why should they be the same? If they were to be the same, then which party would be in charge of making decisions for everyone else? – Erik Eidt Jul 05 '21 at 21:36
  • You should edit your question with specific examples of what is confusing to you so people don't have to guess. – Mark Tolonen Jul 06 '21 at 04:15

2 Answers2

3

Could somebody shed some light on it?

Differences that you might see:

  1. There's multiple dialects of assembly. 2 main dialects are MASM (invented by Microsoft and preferred by their tools) and AT&T (the default for tools designed for *nix clones). These are very different dialects - different operand order, AT&T uses size suffixes on instructions (e.g. movl to indicate you're moving a long instead of mov with the size infered from operands), different operand formatting (e.g. [rax+rbx*4+1234] in MASM/Intel syntax becomes an unintuitive mess like 1234(%rax,%rbx,4) in AT&T), etc.

  2. For 64-bit code; there's different calling conventions - the Microsoft x64 calling convention (used for everything in Windows) and the System V AMD64 ABI (used by *nix clones). This causes differences in register usage and stack management.

  3. The underlying interfaces are different (e.g. VirtualAlloc() vs. mmap(), WaitForSingleObject() vs. pthread_mutex_lock(), etc). Note that this has nothing to do with kernel system calls (there's always a user-space library involved and nothing should ever use the kernel system calls directly) - it's about "Win32 API" vs. "POSIX API" provided by system libraries. Even with compatibility wrappers (e.g. Cygwin's POSIX libraries on Windows) these differences can still make their way into the assembly code (via. macros in headers, etc).

zx485
  • 28,498
  • 28
  • 50
  • 59
Brendan
  • 35,656
  • 2
  • 39
  • 66
  • 1
    I hope you don't mind that I improved the formatting of your list and added two source links. – zx485 Jul 06 '21 at 02:45
1

Should be no different than anything else you have worked on. If the question is linux vs windows on the same machine/platform then obviously it is the same instruction set.

As you know, assembly language is specific to the tool, the assembler, not the target, and for x86 there are countless different incompatible assembly languages for the same instruction set (not just some at&t vs intel thing, many incompatible at&t assembly languages for the same processor). So there is that, you can, for example, go the gnu and/or llvm route and as far as the assembly langauge the experience can/will be the same.

But then you get into operating system and there is no reason to assume the same processor with different operating systems have the same system calls, they might use the same instruction to do a system call but always assume the calls vary between operating systems and from time to time within the same operating system family.

So how the C library connects to the system is expected to vary, but that is why there are these layers of libraries yes?

The high level (C, C++) calling convention ideally will be the same if you stick to say gnu tools of the same version, etc between the operating systems on the same platform. But that can vary, the gnu tools have options, and someone compiled the compiler itself and it has options.

If you are not going to work at the assembly language level or if it is minimal (as it should be) then most of this is irrelevant, the instruction set is just like french or spanish or english, and the operating system is a biology book or romance novel, etc. From a programmers perspective (not counting performance tuning) you program in some high level language and the lower level target is the lower level target. Just like paper, ink and the alphabet in a book, that is just the vehicle that moves the information.

While assuming that gcc, clang, etc are the same C and asm programming languages within the tool, that does not mean, as pointed out in comments, that the compilers on each platform will produce the same exact code from the same high level code (one should never expect this). The native versions of the tools even if from the same original code base, will be different for each target, mostly in the system calls and the linker scripts, but there may be other options that the builder of the tool has chosen and no reason to assume the builder of the linux tool for some distro is the same as the builder of the same tool for some pre-built windows binary...

If you have experience with microprocessors and assembly language and all of that, you know all of this so this question is quite confusing

old_timer
  • 69,149
  • 8
  • 89
  • 168
  • The GNU toolchain on Windows targets the native Windows calling conventions. (Including Cygwin). Same for clang. [Why does Windows64 use a different calling convention from all other OSes on x86-64?](https://stackoverflow.com/q/4429398). It's possible to build or download an i686-linux-elf cross-compiler for Windows, or maybe even a compiler that uses x86-64 System V for calls between your functions, but still MS-abi for calls to all other functions (i.e. Windows DLLs). – Peter Cordes Jul 06 '21 at 01:00
  • Unless you mean "ideally" as "what you wish they'd done". – Peter Cordes Jul 06 '21 at 01:01