Why There is a difference between assembly languages like Windows, Linux?

Question

I am relatively new to all this low level stuff,assembly language.. and want to learn more detail. Why there is a difference between Linux, Windows Assembly languages?

Answer 1

There exist a few assemblers for various platforms which, given a source file, will produce an output binary file directly which is designed to be loaded at a particular address. Such assemblers have been popular for some small microcontrollers, or for some historical processors like the 6502 and Z80. When assembling the program, it would be necessary to know the address where it would be expected to reside; using a different address would require re-assembling the program. On the other hand, assembly in such a system was a single-step process. Run the assembler on the source code and get an executable output. In some cases, it would be possible to have the source code, assembler, and output all in memory at once (on my Commodore 64, I used an assembler which was published in Compute's Gazette magazine that worked like that).

Although reassembling everything any time its address changes might have been practical for a program that will "take over the machine", in many cases it's desirable to use a multi-step process where source files are processed into object-code files, which contain the assembled instructions but also contain various kinds of "symbolic" information about them; these files are then processed in various ways so as to either yield a memory image that may be loaded directly into memory, or else a combined relocatable object file which an operating system's loader will know how to adjust for any address to which it might be loaded.

In order for an object-linking system to be useful, it must allow certain kinds of address computation to be deferred until a program is linked or loaded. Some systems only allow extremely simple computations to be performed at link/load time, while others allow for more complicated computations. The simpler schemes may be more efficient when they're workable, but their limitations may force workarounds. As an example, a routine which will be using BX to loop through a data structure with less than 256 bytes might be written as something like:

    mov bx,StartAddr

lp: mov al,[bx] ... do some computation inc bx cmp bl,<(StartAddr+Length) ; < prefix operator means "LSB of" jnz lp

It would be possible to use cmp bx,(StartAddr+Length), but if the compilation tools can support it, comparing just the low byte would be faster. On the other hand, some kinds of 16-bit assembly/linking tools might require that all address fixups be done with 16-bit addresses stored in code.

Because different systems allow for different features in their object-code formats, they require different features in their assembly languages to control them. The instruction sets may be specified by the chip manufacturer, but features for expressing relocatable address computation generally are not.

Answer 2

Unless you are using an embedded system development environment, you are compiling with compilers that are targeted to a particular runtime. That runtime defines the conventions for the use of the hardware: argument passing, exception handling, etc. These conventions interact with the operating system, or at least with the available runtime libraries that the program needs to link with.

Answer 3

Well, you don't run straight assembly. The code has to be in some sort of executable format: windows uses PE, most Unices use ELF now (although there have been others, like a.out).

The base assembly instructions are the same, and the functions you create with them are the same.

The problem comes with access to other resources. The processor is really good at calculation, but can't access the hard disk, or print a character to the screen, or connect to a Bluetooth phone. These elements are always in some way operating system dependent. They are implemented in terms of syscalls, where the processor signals the operating system to perform a certain task. Task number 17 on linux isn't necessarily task 17 on windows; they may not even have equivalents.

Since most libraries have some syscalls at their lowest levels, this is why code can't just be recompiled in every case.