OSDev.org

bluemoon wrote:I don't know why anyone would want to write boot loader with 16-bit C. It's so obvious that writing a early stage (with do all the necessary real mode functions) with assembly is straightforward*, and any complex logic could be implemented with 32-bit C after entering protected mode or long mode.

* By straightforward, I meant a reasonable early stage boot loader can be implemented in about 500 lines of assembly code.
* In contrast, insist to do that with C you not only end up with almost equal amount of (inline) assembly, but also suffer from the lack of tools.

I have just completed this exercise with respect to the "lack of tools" issue. Note that I was referred to this thread by someone not here.

PDOS/386 (as of an hour ago) now has the ability to build the 16-bit bootloader with PDOS/386 itself. Meaning the required tool is now on PDOS/386 itself. Which means it is a C90-compliant program. That program is "sccdos.exe" - my fork of SubC. The compiler itself is not 100% C90 conformant, but it is sufficiently conformant for my coding style at least. I did have to make some changes to my code because SubC is only small memory model, but my bootloader was previously huge memory model (and before that - large).

Note that "huge" is the technically correct thing in my opinion.

Regardless, for someone like me who struggles with assembler (I'm probably 50 times more productive in C), I dispute that bootloaders shouldn't be written in C. I don't want to see any while or if in assembler. I am happy for small assembler routines.

I wasn't required to use inline assembly at all. Not sure why you would think that was a requirement.

I do call fairly small assembler routines, but they're in separate (masm-compatible) source files.

The switch to PM32 requires more assembler, but there is no way to do that in C anyway, and regardless there are no loops or ifs. That is 500 lines of assembler just for itself. Well, my version has more things in it to allow a return to RM16.

All available on the PDOS/386 hard disk image at http://pdos.org or start with this batch file:

https://sourceforge.net/p/pdos/gitcode/ ... comp4w.bat

As we're resurrecting the thread, I'd like to add that Linux, in the past, used C for some real-mode boot code too. As I recall from documentation at the time, the compiler was BCC. Its author made it available under a suitable licence as there was no other 16-bit C compiler under a license suitable for Linux at the time. It's never been a great compiler, not even in its author's own opinion, but it's relatively simple and includes an assembler and a linker. It compiles K&R C, an informal standard which predated even the earliest ANSI standard for C.

I've also found BCC on FreeDOS disks. Other finds were Watcom C and Pacific C; both complete development environments. Watcom C was something of a rock star of the DOS era and remains a fairly serious bit of kit. @rdos uses it to compile his OS which sees some pretty serious use in industry. It's still maintained as OpenWatcom. It compiles ANSI C, an older standard than @kerravon's new sccdos.

Pacific C I mention for completeness. It's freeware, not open source, and may not be able to generate programs for anything other than DOS. It also compiles ANSI C. It has a nice IDE which includes a C language reference, but it doesn't work too well on my 2007 hardware. (DOS programs can be like that.) It may have been bundled with FreeDOS 1.0 only because it compiles the classic GEMDOS desktop environment.

Given the immense popularity of MS-DOS in the 80s and 90s, and the glamour of C in the era despite its reputation for being bloated and slow -- relative to assembler -- I'm surprised that more 16-bit C compilers haven't come to light.

There is now also a 16-bit port of GCC available here: https://github.com/tkchia/gcc-ia16.
From what I've seen, it is at least comparable to BCC, and definitely more usable than stock "gcc -m16". Too bad the implementation of pointers still sucks in this port, and the null pointer address is actually 0, which means there is no defined way to set the first interrupt handler.

Are there any real-mode-x86 C compilers with good pointer implementations?