Re: C 16 bit compiler

"Jack Smith" <ilikequoting@katamail.com> wrote in message


> Do you know about a compiler C which can compile into 16 bit? i've
> tried watcom, but it's difficult to use and i need that 16 bit binary
> to be an ELF, not an OMF, besides ELF is rudimentary in wlink.
>


16-bit C compilers... I am not sure, but I will list off what comes to
mind...


AFAIK, 16-bit ELF is itself non-standard (I doubt a C compiler will be found
which can produce this format natively), and it is likely better that one
just live with the OMF, or link into a raw binary image or similar.


besides Watcom, old TurboC or similar compilers exist (still produce OMF
objects though). dunno the specifics of getting ahold of older TurboC
though, not looked into this.


IIRC, there is also Minix, which IIRC had a compiler available which could
produce 16-bit a a.out variant or similar (I really don't remember if it had
source or not, but I think it did, but I could be wrong).


IIRC, lcc also had a 16-bit nasm target (lcc was available in source form,
and various people customized it for various targets).




> The more general question, suppose you have to write a bootloader
> (only stage1) in C and in real mode, what compiler will you use?


a lot depends on how exactly you want to do it, what tools one has
available, ...




my thoughts:
for a bootloader one is better off skipping C.
a bootloader is small and cramped enough that usually the only really good
option is ASM, but OTOH, it is typically small enough that ASM is managable
for the task.


typically, if C is used, it is usually for the "second stage".


say, typical boot process:
first stage gets the second stage and kernel loaded into memory;
second stage may be ASM or C;
the second stage will typically copy or decompress the kernel to a higher
memory address, setup protected mode, ...


likely the second stage could be most easily linked into a raw binary or a
".com" file (which is basically a raw binary file with a load and start
address of 0x100), however, some special care will be needed to produce a
standalone file (naively using a DOS compiler would produce a file which
assumes DOS to exist).


MZ-EXE is also possible, but MZ requires fixups' prior to use (could be an
issue for a bootloader).




one can also append the files together, which could save loading multiple
files (if one is using raw images, but could pose a few added issues, so
loading multiple files into memory is a little simpler). also possible
though is to only use the bootloader to load the second-stage, which is
itself responsible for loading any other files (say, kernel image and any
startup modules).


admittedly, in my case (back when I was into OS's), I wrote the second stage
in ASM as well (as I also lacked a decent 16-bit C compiler).


unless one is intending to have a lot of general-purpose logic code in
realmode though, it is unclear what real advantage there is to using C here
(to be worth the hassle of getting ahold of/using a 16-bit C compiler). a
lot of low-level OS tasks are not particularly well suited to an HLL like C
(since a lot of it tends to be messing around with the BIOS and with the CPU
state). this is especially true if the loader logic is done partly/mostly in
"big real" mode, which is unlikely to really be supported by compilers
anyways, but big-real is IME one of the most convinient ways to handle mixed
real-mode and protected-mode logic (since one has full access to the memory
map, ...).




a possible option is to use MZ-EXE + PE/COFF, but MZ-EXE (for the real-mode
portion) would require segment fixups. if used, this would then work vaguely
similarly to a DPMI loader, where the 16-bit portion first gains control
first and then sets up and jumps into the 32-bit portion of the image. in
this case, the bootloader would effectively function similarly to a sort of
micro-DOS or similar.




back when I wrote an OS (early 2000's), I was using PE/COFF for binaries,
but this was because I was building on Windows and so PE/COFF was the most
convinient format (one just supplies all their own library code). at the
time, I was using only static linking though (my loader didn't support
DLL's, or loading at non-default addresses, for that matter...).


back then, both my bootloader and second stage were written in ASM though
(where the second stage continued being used after the kernel was loaded and
after switching to protected-mode, where it mostly served as a real-mode
interface for using the BIOS and similar, and contained most of the logic
for switching between realmode and pmode).




even now, I would probably still use PE/COFF as a matter of personal
preference (the format is a little ugly, but it is fairly easy to work with
IME). between PE/COFF and ELF I am not sure which is easier to do a loader
for though (not personally written an ELF loader, so I am not sure).


more recently for other reasons (an x86 emulator/interpreter), I did
implement a full PE/COFF loader with DLL support (it was not particularly
complicated).




> ah, yeah..unfortunately.. gcc is not suitable for this,
> because .code("asm16gcc"); directive makes the compiler to insert a
> lot of 66 and 67 stuff in the code which makes the binary too large
> for my purpose, moreover someone says that it will not work either, do
> you confirm this?.
>
> any help is appreciated..
>


can't really comment much on this...




sorry, I really don't know if any of this is much help...


maybe check 'alt.os.development', 'alt.lang.asm', or 'comp.lang.asm.x86',
since the people on these groups are much more into this and are more likely
to be able to provide helpful answers...




or such...

Return to the comp.compilers page.
Search the comp.compilers archives again.