NASM vs. FASM

[Jubbens]

I'm re-writing my OS, now in 100% my own code and 100% pure assembly. These are the two assembly compilers I was thinking of using, but I'm stuck betweern them.

Are there any benefits/drawbacks for OS development in each, or will they be pretty much the same? From what I'm hearing it looks like NASM should be the easiest here. Is there any other assemblers I should take a look at?

Thanks

[Curufir]

FASM has nice macro support, is (AFAIK) more actively developed and can be ported to your OS far more easily (It's self-assembling) than NASM (Which requires a full C environment).

[Jubbens]

wow....didn't know that. I'll use FASM unless someone suggests a better one for my uses.

And didn't FASM get ported to MinuetOS? (...or something? Been so long.) How does one port an assembler?

[Dex4u]

How many other assemblers come with a manual on how to convert the assembler to run on your new OS ?, see here:
http://board.flatassembler.net/topic.php?t=1972

I started with nasm on my OS, but changed to fasm, and i could never go back to nasm.
One of the best things i like about Fasm is error checking, nasm gives you a line number, not easy to find, but Fasm show you the content of the line that coursed the error.

So my advice is go with FASM.

[Neo]

Is there a CYGWIN(/Linux) version of FASM?

[DruG5t0r3]

there is a linux one, google a bit dude...

[pini]

I'm using FASM too.
I found some features very useful, compared to NASM : anonymous labels, macro support, and computing on symbols. For example of the last, you can define a label and then compute things like

Code: Select all

((my_lbl shr 12) and 0xFF00) or 0x3

which is very useful to construct tables, like GDT and IDT without the need of construction code.

[Pype.Clicker]

I'm using FASM too.
I found some features very useful, compared to NASM :
anonymous labels,

Maybe you could elaborate a bit more on that one, but NASM had a lot of features concerning labels, among other local labels (e.g. you can have .loop at several places provided they are in different functions), macro-local labels, etc.

macro support,

NASM has it too, and NASM's macros are especially powerful, allowing a context stack to be manipulated (so that your macros can nest, etc)

and computing on symbols. For example of the last, you can define a label and then compute things like

Code: Select all

((my_lbl shr 12) and 0xFF00) or 0x3

which is very useful to construct tables, like GDT and IDT without the need of construction code.

okay, that one was a bit harder to get working since i got messages saying "operator >> can only be applied on scalar values", but just patching to

Code: Select all

[org 0]
my_lbl:

my_modified dd (((my_lbl-$$) >> 12) & 0xff00) | 3

Honnestly, the only "real" argument i see to prefer FASM is that it is self-compiling... yet i'm not sure it is a so great advantage: you could easily compile a version of NASM that matches your own OS on your DevStation (tm) and run the binary in your OS after that...

[smiddy]

Sure, Pype.Clicker, it isn't as hyped a difference as may be presented. However, the work involved in creating a DevStation with a corresponding C compiler would take more time.

I used NASM for a while and then moved over to FASM as well. My main reasoning is that it has specific support for it. It is moving into 64-bit environments as well (I beleive AMD support is done).

[bubach]

fasm is smaller and self-compiling, that should be enought reasons to choose it.
Other then that, it only differs on small syntax stuff.

[Pype.Clicker]

if i compile NASM and then ndisasm it, it will produce self-compiling nasm

[Solar]

Regarding the self-assembling... I consider the Assembler to be a crutch that is necessary until higher level languages (C, C++, ...) become available for your target.

So I would be heavily working towards a complete C environment anyway... at which point the difference becomes mood.

Speed? I don't expect to reassemble that often, and even then, how big can the difference be, considering the power of the development systems we all are using today?

"More actively developed" weights much heavier in my opinion...

Just my 0.02?. (And since I am using GNU 'as' / AT&T syntax, you can probably discount me as nutcase anyway. )

[smiddy]

Solar your point is well taken, better environments breed better (more) off-spring (to be analogical). But the point was either NASM or FASM. I think FASM is more useable than NASM especially given its current AVAILABLE support. Most assembler programmers would contend that using an assembler written in assembler seems more closely related to the programming the programmer is doing. Not to be prejudiced but rather a purest to the ART form. But then again, I'm a cynic.

[bubach]

if i compile NASM and then ndisasm it, it will produce self-compiling nasm

Well, have fun trying to get that disasm output to assemble fine..

[Jubbens]

I think I opened Pandora's Box with this thread.

FASM it is.