For a particular architecture (i.e. CPU type) the assembly language is the same. Realize that even modern intel CPUs have different instruction sets but in general most compilers stick to common instruction sets shared amoung all intel CPUs unless advanced instruction sets (aka extensions) are specifically enabled. MMX was one such extension.
Assembly really doesn't have much to do with device IO or drivers since assembly is *below* the operating system. In assembly, you write to or read from (poke/peek) memory locations which may be mapped to devices or be actual memory. If you are actually programming in assembly (not in a compiled language) then you'd just have to know what locations mean what. This "abstraction" is what the OS and compilers provide to higher level languages.
What you are confused about is binary executable format which *is* os dependent. Every executable binary contains information in it that helps the OS know how to run it and what it's called and so forth. Binaries contain the assembly instructions that needs to run but modern binaries are also often not self standing. The "assembly" code in a binary has to be "loaded" and run along with any other "shared" binary code fragments (i.e. shared libraries). This is where the portability breaks down. On the hardware abstraction side, there is also some runtime adjustments that the OS has to do in order to map the right locations into the assembly code. This is because hardware today are not in fixed predictable locations. The bios can move a device from one memory address to another at boot time or even at run time. This is basically what PnP is. It provides a way for the OS to modify how the bios positions hardware in memory to avoid conflicts. That is why if you are running an OS that is *not* PnP aware, you need to disable the feature in the bios so that the bios will initialize and fix those parameters for the hardware at boot time. Once the OS is done with relocation and device mapping, the "code" that is sent to the CPU is assembly and for all intents and purposes this code would be basically the same no matter what OS is used.
So what are some binary formats that are shared... well, ELF is one. Elf is used on various Unix and Unix-like OSs such as Linux and Solaris. Unfortunately binary compatibility is not a useful reality because it requires all the shared components to be compatible versions and format. In a sense, the WINE project in Linux is an attempt to emulate the Windows HAL (Hardware Abstraction Layer) in order to "load" a binary and do all of the necessary relocations for IO and shared components that windows does and then send it to the CPU. In a way, WINE is an attempt to create binary compatibility with windows "EXE" files.
7/18/2008
A difference and what is it between assembly language in Linux and Windows
Posted by
admin
at
7/18/2008
Labels: Linux
Subscribe to:
Post Comments (Atom)
0 comments:
Post a Comment