Re: C 16 bit compiler

George Neuner <>
Sun, 03 Oct 2010 01:17:49 -0400

          From comp.compilers

Related articles
[2 earlier articles]
Re: C 16 bit compiler (Nils M Holm) (2010-09-29)
Re: C 16 bit compiler (BGB / cr88192) (2010-09-28)
Re: C 16 bit compiler (George Neuner) (2010-09-29)
Re: C 16 bit compiler (2010-09-30)
Re: C 16 bit compiler (Jack Smith) (2010-10-01)
Re: C 16 bit compiler (George Neuner) (2010-10-01)
Re: C 16 bit compiler (George Neuner) (2010-10-03)
Re: C 16 bit compiler (BGB / cr88192) (2010-10-06)
Re: C 16 bit compiler (Walter Bright) (2010-11-11)
Re: C 16 bit compiler (Marco) (2010-11-20)
| List of all articles for this month |

From: George Neuner <>
Newsgroups: comp.compilers
Date: Sun, 03 Oct 2010 01:17:49 -0400
Organization: A noiseless patient Spider
References: 10-09-027 10-09-033 10-10-002
Keywords: C, code
Posted-Date: 05 Oct 2010 13:47:04 EDT

On Thu, 30 Sep 2010 03:42:04 -0500, wrote:

>On Wed, 29 Sep 2010 16:31:09 -0400, George Neuner
><> wrote:
>>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.


Post a followup to this message

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