Assembler of choice
-
William
Assembler of choice
For those of you out there building OS using pure assembly, would you recommend FASM to do the job? It is quite new, but quite some people are praising it already. I usually heard the more mature NASM being used for OS development, and was wondering which would be a more appropriate choice.
-
Schol-R-LEA
RE:Assembler of choice
Just to clarify the subjects for everyone:
Netwide Assembler - http://nasm.sourceforge.net/
Flat Assembler - http://fasm.sourceforge.net/
Gnu Assembler - http://www.gnu.org/manual/gas-2.9.1/as.html
Linux Assembly Programmming HOWTO (includes a list of assemblers and some excellent advice on when and when not to use assembly language) -http://www.tldp.org/HOWTO/Assembly-HOWTO/index.html
And that only scratches the surface.
As for which one to use, the real answer, regardless of anything else, is "whichever one you feel most comfortable with".
OTOH, there are probably more programmers who know Netwide Assembler than any other x86 assembler out there today - including MASM - and it is available on several platforms.
GAS, however, is even more mature, and is on nearly *every* platform available, but it is rarely used - few x86 programmers are comfortable with AT&T syntax, and gas does not support hand-coded assembly programming well (it is primarily designed as a backend for gcc). The fact that NASM caught on so quickly when gas was already widely available should tell you how important it is to have tools that meet your needs as a programmer, not the other way around. Still, there are those who prefer the AT&T syntax - it is in many ways simpler and more consistent than the Intel syntax, and is used widely on non-Intel CPUs - so again it is a matter of what you as a programmer want to use.
You do have to consider your 'target audience', however - the programmers who will want or need to read this in the future. Also, in the case of cross-assembly to a new platform (i.e., the OS your developing...) you will want something that is readily portable to the target platform.
For my own part, my experiments at present are in NASM, which seems the best bargain around for my needs. However, when I ditch my practice code and begin work in earnest, I will probably write my own assembler, tailored to the needs of my system design and programming style - given what I intend to do, I know that no existing assemblers and compilers will fit the bill. But that is what is right for *me*. Only you can decide what is right for you...
Netwide Assembler - http://nasm.sourceforge.net/
Flat Assembler - http://fasm.sourceforge.net/
Gnu Assembler - http://www.gnu.org/manual/gas-2.9.1/as.html
Linux Assembly Programmming HOWTO (includes a list of assemblers and some excellent advice on when and when not to use assembly language) -http://www.tldp.org/HOWTO/Assembly-HOWTO/index.html
And that only scratches the surface.
As for which one to use, the real answer, regardless of anything else, is "whichever one you feel most comfortable with".
OTOH, there are probably more programmers who know Netwide Assembler than any other x86 assembler out there today - including MASM - and it is available on several platforms.
GAS, however, is even more mature, and is on nearly *every* platform available, but it is rarely used - few x86 programmers are comfortable with AT&T syntax, and gas does not support hand-coded assembly programming well (it is primarily designed as a backend for gcc). The fact that NASM caught on so quickly when gas was already widely available should tell you how important it is to have tools that meet your needs as a programmer, not the other way around. Still, there are those who prefer the AT&T syntax - it is in many ways simpler and more consistent than the Intel syntax, and is used widely on non-Intel CPUs - so again it is a matter of what you as a programmer want to use.
You do have to consider your 'target audience', however - the programmers who will want or need to read this in the future. Also, in the case of cross-assembly to a new platform (i.e., the OS your developing...) you will want something that is readily portable to the target platform.
For my own part, my experiments at present are in NASM, which seems the best bargain around for my needs. However, when I ditch my practice code and begin work in earnest, I will probably write my own assembler, tailored to the needs of my system design and programming style - given what I intend to do, I know that no existing assemblers and compilers will fit the bill. But that is what is right for *me*. Only you can decide what is right for you...
-
geezer
RE:Assembler of choice
I used NASM for the startup code of my OS, but I switched to AS because I want my OS to build under DOS, Windows, or Linux. NASM 0.98 doesn't work with ELF if you add user-defined sections to the ELF file (the latest version of NASM fixes this). NASM also fails when used with CygWin or MinGW32, but this is because of a bug in those compilers.
Many functions in my C library use inline asm. With inline asm, you don't have to worry about leading underscores on C symbols (DOS and Windows compilers do this, Linux does not).
In many OSes, each syscall function (e.g. read, write, ioctl, sbrk) has a number. The numbers are defined in a #include file, for use by both the kernel and the C library. If you write syscall functions in non-inline assembler, you need a separate (asm) include file for these numbers. This is bad. If the two files get out of sync with each other, your kernel will stop working.
I still use NASM for my loader. AS isn't very good for 16-bit code.
Many functions in my C library use inline asm. With inline asm, you don't have to worry about leading underscores on C symbols (DOS and Windows compilers do this, Linux does not).
In many OSes, each syscall function (e.g. read, write, ioctl, sbrk) has a number. The numbers are defined in a #include file, for use by both the kernel and the C library. If you write syscall functions in non-inline assembler, you need a separate (asm) include file for these numbers. This is bad. If the two files get out of sync with each other, your kernel will stop working.
I still use NASM for my loader. AS isn't very good for 16-bit code.
-
carbonBased
RE:Assembler of choice
Just a little thing:
Linux _will_ use underscores to prefix C symbols if the system is A.OUT
It's not Linux that doesn't use underscore prefixes, it's ELF. If a new DJGPP version were to support ELF objects, it to wouldn't use underscore prefixes.
Jeff
Linux _will_ use underscores to prefix C symbols if the system is A.OUT
It's not Linux that doesn't use underscore prefixes, it's ELF. If a new DJGPP version were to support ELF objects, it to wouldn't use underscore prefixes.
Jeff