4 ms·
I feel your pain, so sorry that you still need to support the .code16gcc hack! My first approach was actually to avoid GCC/clang altogether, and use Turbo C ins
by qx89l4 7y ago
I feel your pain, so sorry that you still need to support the .code16gcc hack! My first approach was actually to avoid GCC/clang altogether, and use Turbo C instead. It came with its own set of problems, but the output was much more predictable. In case you're interested, you can find the code at https://github.com/luke8086/nf https://github.com/luke8086/nf
- oso2k 7y agotkchia [0] has been working on getting gcc to emit 16-bit clean code (no 32-bit code prefixes) along with ancillary tooling like binutils, a couple different libc's, and some of the things you'd expect from a 16-bit x86 C compiler like far pointers and DOS-specific libc functions [0]. The use case is to build the FreeDOS Kernel and ELKS 16-bit Linux Kernel from a 32-bit or 64-bit Linux system. [0] https://github.com/tkchia/gcc-ia16 https://github.com/tkchia/gcc-ia16 [1] https://github.com/tkchia/build-ia16/releases https://github.com/tkchia/build-ia16/releases