OSDev.org

Hello friends

I am developing an OS and confused a lot which assembler and linker to use NASM or GAS.
I have read many BOOKs and many say use NASM and many says Use GAS so which one will be actually better for a large development program.

Please answer sincerely since I want to make a grand project and even highlight your reason why you prefer your choice

Thanks in advance.......

I don't think it really matters which one you choose. The biggest difference between the two is the assembly syntax they support, but you can write the same code equally well in any syntax. The only other difference I'm aware of is NASM's built-in linker for flat binaries; GAS requires you to use an external linker even if your target is a flat binary.

Personally, I find NASM syntax much easier to read and write than AT&T or Intel syntax, so I would choose NASM.

Long time ago I chose GAS. Still using it.

Main reasons:

• You do not need to install another tool. AS is included with GCC (or was that Binutils?). Then there is no difference whether you compile .c or .S files.
• It's the syntax you get when disassembling with objdump -d. You do not have to "switch brain modes" to understand what's going on.
• It's what you get in GDB if there are no sources loaded or you want to instruction-step into C code.

As I said it was long time ago. Since then I've learned that tools have command line options to switch the syntax. But I'm sticking to defaults anyway.

Which is better NASM or GAS?

FASM. Period.

If you're asking which one has the better language support, then I say that's a personal preference. (NASM uses Intel syntax, GAS can use both AT&T and Intel syntaces). But you should be able to convert between these dialects, if this is a problem, then maybe Assembly and OSDev is not the best hobby for you.

If you're asking which one has the better instruction coverage, then I say both are good enough. That is, for x86. NASM can't compile to ARM, GAS and FASM can.

If you're concerned about your build environment, then GAS is already included with GNU toolchain, NASM has to be installed separately.

If you are asking which is the fastest, most memory efficient, easiest to port, has the most advanced macro capabilities, then the answer is FASM, no doubt. (You can calculate checksums using only macros in FASM, something impossible with NASM and GAS. And this is just one example.)

Cheers,
bzt

NASM, its syntax is much easier/cleaner and it is easy to use.

GAS, since it is included in the binutils which you need anyway.

There, now you've had opinions for all choices. I'm only waiting for a TASM proponent to show up.

And, for our Windows friends, there's MASM.

They all do the same job. I stick with GAS - why introduce more tools when you already have ones that do the job?

Ooh, one more argument for GAS that might be more meaningful once you get to userspace: GAS has support for all specified ELF relocation types. NASM support for such is a bit spotty (for instance, as I recall, it is impossible to emit TLSIE relocations). Not that you need that in a kernel, since a kernel has no loader to set this all up, and usually no thread pointer, either.

nullplan wrote:Ooh, one more argument for GAS that might be more meaningful once you get to userspace: GAS has support for all specified ELF relocation types. NASM support for such is a bit spotty (for instance, as I recall, it is impossible to emit TLSIE relocations). Not that you need that in a kernel, since a kernel has no loader to set this all up, and usually no thread pointer, either.

Unless you write one, that is. It wouldn't be too difficult to get a kernel to parse itself, even... I've done that before.

But my current kernel has a separate loader that includes a dynamic linker.