SectorC: A C compiler that fits in the boot sector

We have previously seen SectorLISP and SectorForth, and now a character going by ‘xorvoid’ has produced SectorC. Like the other two projects that inspired it, it is a boot sector that implements a programming language. There is a great writeup here:

https://xorvoid.com/sectorc.html

The (assembly) source and a boot image are available here:

It is a very interesting take on the sector-language-environment, and different from SectorForth and SectorLISP in a couple of notable ways:

  • C syntax is MUCH more complicated than either Lisp or Forth
  • Unlike Lisp and Forth, C cannot “extend itself”, so the environment you boot with is the environment you have

This project compiles native code directly from the C input, and then jumps to it. It implements a rather small subset of C, and uses an observation of the author that you can simplify C lexing and parsing by restricting the usage of whitespace and some other features of the grammar, to subset “proper” C into something more tractable. By providing “asm” statements which drop integer values directly into the source code where compiled, escape hatches into the BIOS or native hardware can be easily provided, and indeed the included examples include VGA graphic animations.

An illustration of the notion of restricting whitespace to make parsing easier is that if( and ){ become “tokens” in SectorC, meaning that parsing an if statement can be reduced to processing the (effective) tokens IF expr THEN statements END.

The big limitations (as I see it) of SectorC are:

  • No function arguments
  • No local variables
  • No arrays

The first two can be worked around with careful global selection (like BASIC!), and the third can be worked around with pointers, because it does have pointers – although it does not have multiplication, so again, careful usage is required.

While it is clearly a toy at this stage, it does lead to the question of exactly how much more than a boot sector would be required to develop a C compiler complete enough to compile a much more capable C compiler. In this respect it reminds me of something like the MES project, which implements a small C compiler (about 3k lines) in Scheme and a small Scheme interpreter (about 5k lines) in C which are capable of compiling/interpreting each other. SectorC is an order of magnitude smaller than those, but I would suggest significantly less than an order of magnitude less capable.

4 Likes

Function arguments are needed, at least for calling functions,
if you can’t call I/O, it is not even a toy as even a toy can
write a “hello world” program.
https://muppetlabs.com/~breadbox/bf/
++++++++[>++++[>++>+++>+++>+<<<<-]>+>+>->>+[<]<-]>>.>—.+++++++…+++.>>.<-.<.+++.------.--------.>>+.>++.

Because; Naturally, BF always needs to come and crash (literally) every low-level systems party regardless of whether it was even invited. …

Your mission, oldben, should you decide to accept it is to write a BF interpreter in SectorC then implement your own Hello World program in it …

As always, should you or any of your software task force be caught or killed, the moderator will disavow any knowledge of your actions. This paper tape will self-combust in ten seconds. Good luck, oldben.

-Gordon

1 Like

You may wish to look at the actual project, which includes examples of both textual I/O and a graphics demo with an animated VGA sine wave.

1 Like

To be fair, if there wasn’t any argument passing and no magic static buffers, this would be a rather philosophical language. (Maybe called Falling Tree in a Wood … but you could still listen on any side-channels… :slight_smile: )

I forgot about memory mapped I/O. I was thinking more of operating system calls here.
Ben.