> Currently it generates 16-bit and 32-bit 80386+ assembly code for NASM that can then be assembled and linked into DOS, Windows and Linux programs.
I wonder why not 64Bit? Hardly anyone uses 32bit processors anymore, and even in the Windows world 64Bit systems are slowly taking over, so it would seem more logical to me to compile for modern processors, instead of 16bit architecture.
That is so but the subset of x86_64 that you'd use for code generation is pretty much the same as the subset of x86 that you'd use for code generation.
- additional 64-bit types will need additional code for type checks and conversions, switch, etc
- new or improved code generator is needed (ideally, 64-bit non-pointer types should also be supported in 32-bit programs, possibly as register pairs)
- new object and executable formats to handle
- possibly new ABIs to support (pushing arguments onto the stack and never bothering to align the stack pointer onto a multiple of 8 or 16 boundary is kinda easy, it's pretty much free)
I wonder why not 64Bit? Hardly anyone uses 32bit processors anymore, and even in the Windows world 64Bit systems are slowly taking over, so it would seem more logical to me to compile for modern processors, instead of 16bit architecture.