How do assembly languages depend on operating systems?

As An assembly language implements a symbolic representation of CPU instructions which are independent on OSes while assemblers are always running under some OS, I was wondering how assembly languages depend on operating systems? For example, will assembl开发者_C百科y languages be the same for the same CPU with different OSes? Thanks!

As others have pointed out, system calls and interrupts are different. I can think of another few differences.

The instruction set is the same across all OSes on a given processor, but the executable file format might not be. For example, on the x86, Windows uses the PE format, Linux uses ELF, and MacOS uses Mach-O. That means that assemblers on those platforms must produce their output in those formats, which is a difference.

Relatedly, the calling convention could also be different across different OSes. That probably only matters where you are writing assembly code that calls or is called by compiled-code routines, or perhaps where you are writing inline assembler in some compiled code. The calling convention governs which registers are used for what purposes during a function call, so different conventions require different use of registers by calling and called code. They also put constraints on the position of the stack pointer, and various other things. As it happens, calling conventions have historically been a rare example of consistency across OSes in many cases: i believe the Windows and UNIX calling conventions are the same on the x86 (and are all based on the venerable UNIX System V ABI specification), and are consistent across OSes on most other architectures. However, the conventions are now different between Windows and UNIX on the x86_64.

In addition, there may be differences in the syntax used by the assembly language. Again on the x86, the Windows and Linux assemblers used to use different syntax, with the Windows assembler using a syntax invented by Intel, and the Linux assembler (really, the GNU assembler) using a traditional UNIX syntax invented by AT&T. These syntaxes describe the same instruction set, but are written differently. Nowadays, the GNU assembler can also understand the Intel syntax, so there is less of a difference.

The instructions available (and each instruction's semantics, of course) depends on the CPU, not on the OS - so in a way, you are right.

But for most tasks of interest (I/O for example), you have to talk to the OS (making system calls). Cross-platform abstractions over these things don't exist at that level (well, you could try to use libc for instance, but even then you need to know the calling convention used, which can differ between platforms, etc. - in the end, you'd have to put quite some work into building such an abstraction yourself, so AFAIK few of the few people who program in assembly bother to try), to do something not possible with the (OS-independent) CPU instructions, you have to know what OS you're programming for and how to tell that OS to do it.

This doesn't apply as heavily for inline assembly code in e.g. C code, as it is mostly used to make purely CPU-bound computations in a smarter/faster way than the compiler is expected to).

Assembly languages don't depend on an OS, but on the CPU's instruction set.

Only if you call API functions (like for example a Windows API function from inline assembler code in MSVC), you get an OS dependency.

Assembly language has nothing to do with it, you can take your question (how xyz language depends on operating systems) and use C, pascal, ada, fortran, and a long list of other languages and ask the same question with the same answer, the language has nothing to do with it. The system calls into the operating system using the calling convention for the operating system is what matters, IF you are using the same language or a language with the same calling convention as the operating systems definition, that makes life easier but does not lock you into anything. pretty much any language can be used as you likely well know, the standards C, C++, etc as well as the virtual or runtime interpreted, etc java, perl, python, shell script, javascript, etc. They all seem to run on my computer at least. Somewhere (language specific) is a shim that makes the system calls into the operating system in a manner defined by the operating system. Asm makes life easy for some of those languages since you are bound by no rules you can use asm to make that shim between the language calling convention and the operating system call desired. Likewise using asm makes it easy to interface to any calling convention be it language defined or operating system defined.

Also as already answered assembly language is independent of the operating system or any other software running on the cpu. it is tied directly to the cpu's instruction set. Now there is the machine code, the actually bits executed by the processor, those do not change, but the ascii files used to represent those instructions, that language can change but not because of the cpu nor the operating system, those differences have to do with the toolchain. For example x86 att syntax vs intel syntax. Same instruction set, same machine code, different assembly language. and if you look around enough tasm, masm, etc there are many assemblers for x86 and each have their own directives and other toolchain specific nuances.

The assembly language should be the same; as you point out, the instruction set depends only on the CPU and its architectural design. Where you start getting into trouble with different OSs, I believe, is when you start invoking e.g. interrupts (typically for I/O) which can definitely mean programs written for e.g. MSDOS won't work on e.g. Solaris (maybe a bad example).

An assembler translates mnemonics (e.g. jump, mov, add, etc.) from an assembly language into machine instructions. Machine instructions are entirely dependent on the hardware (they represent the hardware/CPU instruction set).

If you ever wanted to come up with an assembly language, you would need to also design/write an assembler that would do the mapping to machine instructions. In that sense if you target a given machine architecture, the assembler should produce machine specific code, not OS specific code. However, the assembler implementation may (and generally is) OS-specific, because of the output program it produces (a Unix executable is not the same as a Windows executable, even though the underlying machine instruction set is x86, for example).

See here what I mean.

The OS doesn't matter. You could have the same assembler on different OSes, you can use different compilers on the same OS, hey, you can even cross compile, targeting different systems.

I think LINKER is responsible for making OS specific executable file format adding dynamic link liabaries (.dll) etc. It stamps for specific OS format file to executable ones.