Re: C 16 bit compiler

On Thu, 30 Sep 2010 03:42:04 -0500, ArarghMail009@Arargh.com wrote:


>On Wed, 29 Sep 2010 16:31:09 -0400, George Neuner
><gneuner2@comcast.net> wrote:
>
><snip>
>>A first stage boot loader can only be up to one device block long.
>
>Not really. While the BIOS or partition table loader will only load 1
>block (of usually 512 bytes), there is absolutely no reason that the
>first block can't just go and load as many more blocks as it wants to.
>I have done that, usually in the partition table loader.


Yes, the boot block can load additional blocks - and usually does
because the OS/program startup loader is typically linked into the
same executable. But you can't use a meta-executable format like ELF
- it needs to be a flat, non-segmented format.


>>Because of this it would usually be written in assembler. It's
>>possible to write one in C, but you have to be *EXTREMELY* careful
>>about using any library functions. Still it would be difficult to get
>>a useful C program to fit into a 512 byte floppy sector.
>Very true. :-)


I want to make sure there's no confusion due to different people
numbering the boot stages differently. I order them based on disk
device boot as Unix does, from zero as :


      0 : device boot block
      1 : file system boot block
      2 : program/OS kernel


For memory devices like Flash and SSD, there may be no file system and
all the bootstrap work is done from the device boot block. In that
case, stages 0/1 are synonymous.


Regardless, if there is a file system, it can't be used until, at
least, stage 2. Stage 0/1 essentially are limited to BIOS functions
and can reference only raw device blocks. That, along with block size
limitations on many devices, is the reason that these stages are
normally written in assembler.


It is perfectly possible to write block loaders in C, but there's
little point to doing so because they are so simple and because few
(if any) C compilers have any BIOS specific functions - usually just
some generic API for invoking software interrupts/traps ... meaning
that you are writing what is effectively assembler anyway and, in
addition, working without access to most of the C standard library.


George

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