Which Assembler should I choose

[cfny1234]

Hi all,
I'm new to OS development.
I've read some basic tutorials of assembly language, but before I go deep into it, I want to know which Assembler is most suitable for OS development.
I've heard about NASM is quite popular but MASM is easier to use as it support high-level-language-like statements.
Which one should I choose?
thanks!

[xenos]

I prefer GAS - simply because it supports many different architectures and it is invoked by GCC anyway, so one can basically write ASM source code using the same syntax as inline ASM in GCC.

Of course, other assemblers can also be used for x86 or x86_64, depending on what your goals are.

[Prochamber]

Hi all,
I'm new to OS development.
I've read some basic tutorials of assembly language, but before I go deep into it, I want to know which Assembler is most suitable for OS development.
I've heard about NASM is quite popular but MASM is easier to use as it support high-level-language-like statements.
Which one should I choose?
thanks!

I wouldn't say MASM is an option for operation system development. It's an abandoned tool by Microsoft that is designed to created to create programs for Windows (formally DOS). I'm not sure if it can generate a raw binary.

The main options are NASM and FASM. There isn't too much difference between them.
The most popular assembler is NASM, so you'll see a lot of tutorial code in NASM but FASM boosts more powerful macros and optimization.

There are other assembler such as GAS or YASM, it's a personal choice really. Have a look on the Assemblers Category on the OSDev Wiki to can find out more about different assemblers.

[Yoda]

I'd say that GAS has ugly syntax and is perfectly suitable only to those who got accustomed to it. Moreover, the GAS syntax is not widely supported throughout other assemblers. MASM is a bit outdated and in some cases has irregular syntax. Try to take NASM or FASM. NASM becomes more and more popular even amongst Linux/Unix programmers who traditionally tied to GAS first. The other distinction of NASM/FASM against GAS/MASM is that they are true cross platform.

[cfny1234]

thanks for all of your replies.
I've search around the difference between nasm and fasm. Most said that nasm is better working with C, and fasm is the choice for writing the OS entirely in assembly language.
Is it true?

thanks!

[dozniak]

NASM becomes more and more popular even amongst Linux/Unix programmers who traditionally tied to GAS first. The other distinction of NASM/FASM against GAS/MASM is that they are true cross platform.

NASM is getting kinda obsoleted by YASM, which can easily parse both NASM and GAS syntax and has a better backend.

[Yoda]

Most said that nasm is better working with C, and fasm is the choice for writing the OS entirely in assembly language.
Is it true?

Probably yes. FASM is written entirely in assembler (i.e. on itself) and has powerful macro language that is capable to do thing sometimes even not very specific for assemblers. But it doesn't mean that NASM has weak macros. It also has powerful macro language although not as FASM. My recommendation is the following: try both. They use similar syntax and if you'll learn one of them, you'll learn both.

NASM is getting kinda obsoleted by YASM, which can easily parse both NASM and GAS syntax and has a better backend.

Yeah, may be. The thing is that I started using NASM before the launch of YASM. So, that's time to check YASM also.

UPD!
Woooo... NO!
YASM is poorly supported and last update was in 2011, while NASM is very actively developed. Seems that NASM won the battle.

[Griwes]

nasm -f elf -o processor/processorasm.o processor/processor.asm
processor/processor.asm:145: error: elf32 output format does not support 64-bit code

Ah, so this was why I ditched NASM. Not going to work around this just to use something that is maintained over something that isn't, but still works perfectly well.

[dozniak]

Woooo... NO!
YASM is poorly supported and last update was in 2011, while NASM is very actively developed. Seems that NASM won the battle.

What the hell are you smoking?

yasm is actively developed:
* PeterJohnson authored 12 hours ago

yasm is also a library, and as such, is better than nasm just like llvm is better than gcc.

[Kazinsal]

Woooo... NO!
YASM is poorly supported and last update was in 2011, while NASM is very actively developed. Seems that NASM won the battle.

What the hell are you smoking?

yasm is actively developed:
* PeterJohnson authored 12 hours ago

Latest Release: 1.2.0
Release Date: October 31, 2011

Also the last two commits were minor bugfixes. The last feature implementation was October 2012, and before that, August 2012. In the meantime, NASM has implemented almost all of the Haswell New Instructions.

Please stop being abrasive and check facts beyond the surface before accusing someone of being in a narcotic-influenced state of mind.

[Combuster]

I'm with Griwes here - regardless of how up to date they are, yasm gets some of the basic things right the way you expect, where nasm will probably never go to fix it.

You want an include? It has to be relative to the working directory, and not the source directory because getting the latter is apparently an impossible task to do portably. (And yes, I was really given that explanation once )

[Kazinsal]

You want an include? It has to be relative to the working directory, and not the source directory because getting the latter is apparently an impossible task to do portably. (And yes, I was really given that explanation once )

You sure about that? I've included things in "Source\kernel\include\video" with my source directory being "Source\kernel" and my working directory being "Source" by doing %include "include\video\foo.inc" a number of times.

[Prochamber]

I'm with Griwes here - regardless of how up to date they are, yasm gets some of the basic things right the way you expect, where nasm will probably never go to fix it.

You want an include? It has to be relative to the working directory, and not the source directory because getting the latter is apparently an impossible task to do portably. (And yes, I was really given that explanation once )

YASM does save a small amount of typing over NASM if you want to use a files deep in the directory tree to include files even deeper but if all the includes are done from a main kernel file it doesn't help at all. To avoid typing out the path every time you could just add the directory to the search path with the include flag that both NASM and YASM support, assuming all your names are different.
I don't see how using the source directory reduces portability unless you are copying whole folders from another project and naming the folder something different. If anything using the source directory increases portability because it works with NASM.

[cfny1234]

thanks all!
I think I'm gonna try both nasm/fasm as Yoda said.
For yasm, it seems not bad as some of you said. But I don't think I have extra time for it at this point as I still have so so much to learn for os development...

thank you guys again!

[Combuster]

If anything using the source directory increases portability because it works with NASM.

I'm not sure if you missed the fact that NASM actually does the opposite of your claim, or you're suggesting that copying behaviour of the masses is always better?

Either way, comparison of nasm, yasm and gcc on a simple include. NASM is the only one demonstrating irregular behaviour here:

Code: Select all

vi folder/test.asm
vi folder/folder.inc
vi folder/test.c
vi folder/test.h

~/dev $ yasm -f elf -o test.o folder/test.asm 
~/dev $ gcc -o test folder/test.c
~/dev $ nasm -f elf -o test.o folder/test.asm 
folder/test.asm:4: fatal: unable to open include file `folder.inc'
~/dev $ cd folder
~/dev/folder $ yasm -f elf -o test.o test.asm 
~/dev/folder $ gcc -o test test.c
~/dev/folder $ nasm -f elf -o test.o test.asm