3 ms·
> 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 w
by linopolus 9y ago
> 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.
- colejohnson66 9y agoThe x86_64 instruction set is a lot more complicated than the x86 one.
- mikebenfield 9y agoWhat do you have in mind here? What x86 code generated by a C compiler is not readily translatable to x86-64 code?
- kevin_thibedeau 9y agoThe additional registers would be useful. Even if sticking to the x32 ABI.
- CalChris 9y agoThat 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.
- yjftsjthsd-h 9y ago> Hardly anyone uses 32bit processors anymore, On the contrary, nearly everyone has a processor that can run 32 bit programs now.
- alexfru 9y agoGoing 64-bit is quite a bit of work: - 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) And the above work hasn't been done.