Optimal assembler for long mode in 32-bit x86 OS

[rdos]

I just found out that WASM cannot generate 64-bit long mode code, and thus I need a new assembler for the long mode part. Looking at the Wiki, it seems like FASM might be the best choice, especially when there are no plans to use 64-bit C in the kernel. FASM seems to be able to create binary images, which seems superior to using an external linker that would need to be customized. A problem is the location of the code, which needs to be considered in a flat memory model. Maybe by using a single 64-bit device-driver, with a fixed entry-point at 4G, the OS loader can just copy the code to 4G and initialize it there?

[Brendan]

Hi,

I just found out that WASM cannot generate 64-bit long mode code, and thus I need a new assembler for the long mode part. Looking at the Wiki, it seems like FASM might be the best choice, especially when there are no plans to use 64-bit C in the kernel. FASM seems to be able to create binary images, which seems superior to using an external linker that would need to be customized.

All good assemblers (that support 64-bit 80x86 assembly) support "flat binary" output (NASM, YASM, FASM, JWASM, GAS, ...).

A problem is the location of the code, which needs to be considered in a flat memory model.

For 64-bit code, it's not too hard to use "RIP relative addressing" to get position independent code (where the address of the code doesn't matter).


Cheers,

Brendan

[bluemoon]

especially when there are no plans to use 64-bit C in the kernel.

Is it not planed, or planed not to?
I truly recommend to reserve the right to drag in C in the future, and I expect it would not induce extra development cost.

[rdos]

especially when there are no plans to use 64-bit C in the kernel.

Is it not planed, or planed not to?
I truly recommend to reserve the right to drag in C in the future, and I expect it would not induce extra development cost.

The plan is that any complex 64-bit device driver will use a microkernel model, and thus run in userland. Because 64-bit device-drivers run in userland, they can use the ordinary userland port of GCC, and thus don't need a special port to run in kernel.

[Owen]

If you're used to WASM, then enhanced fork JWasm would seem to be the logical progression, and integrate well with your existing toolchain.

Alternatively, if you're using GCC for other 64-bit code, GNU AS may be your best bet. I'm sure that the ".intel_syntax noprefix" directive will be your friend if you follow that route