
Show HN: Minimal freestanding C runtime for bare-metal/embedded PC projects - marssaxman
http://www.github.com/marssaxman/startc
======
baruch
It's the basis for another project of his called 'fleet':
[https://github.com/marssaxman/fleet](https://github.com/marssaxman/fleet)

The idea for fleet (and thus for startc) is to work inside a hypervisor (kvm)
instead of real hardware so you get a few devices implemented through virtio
and run on top of that.

His blog post on fleet is at [http://www.redecho.org/2015/10/01/system-
programming-is-fun-...](http://www.redecho.org/2015/10/01/system-programming-
is-fun-introducing-fleet/)

------
calgoo
Hmm would be fun to add something like Lisp or Erlang on top of that and have
the OS boot to the REPL :)

Edit: There is a Erlang project already:
[http://erlangonxen.org/](http://erlangonxen.org/) Edit2: wrong link...

~~~
nickpsecurity
Not to C programmers. ;) Most of those projects are dead now. However, I think
this one was semi-usable and might still be:

[https://news.ycombinator.com/item?id=8955140](https://news.ycombinator.com/item?id=8955140)

------
bro-stick
Not all that useful and the code quality is mediocre. gas has macros to reduce
boilerplate to nearly nothing. String primitives have already been written in
portable C with one liners (see Klee on github). Assembly should only be for
things primitive bootstrapping, really weird alignment issues (such as to
avoid F00F) or crazy but necessary tricks like stackless operation. Higher
level is your friend, low level is "I have a hammer" job security. (I know the
area around p. 1800-2200 of the Intel IA-32 manual too well, I'll probably
never forget PDE and PDT layouts, GDTR-null self-hosting.)

A more interesting trick of exokernel frameworks would be to provide a
consistent interface _across platforms_ such as video, input, storage and
threads made easily accessible like QNX and others have done.

~~~
marssaxman
I'd be happy to hear your suggestions for improving the code. I've done lots
of assembly programming and firmware development over the years, but rarely on
x86, and this project was the first time I've used the GNU assembler. It was a
learning experience, and that's part of the reason I decided to share it.

I actually wrote parts of this library in C at first, but ported them down to
assembler once I got them working, because it felt more elegant to divide my
project cleanly into a 'runtime' library written in assembler and a 'kernel'
program written in C. A matter of taste, I suppose. The use of assembly
doesn't really create a maintenance burden as the target architecture isn't
changing and the library already does everything it needs to.

------
nickpsecurity
Interesting to see where this will go. I believe the common things to choose
when one wants C on minimal runtime are RTEMS and eCOS:

[https://www.rtems.org/](https://www.rtems.org/)

[http://ecos.sourceware.org/about.html](http://ecos.sourceware.org/about.html)

I've always been surprised they weren't modified for use in VM's in the JeOS-
type deployments. I'm sure some components like network stack could use some
security review but I don't think that's why they were ignored. eCos's
configuration options were particularly a strength as you could keep just what
you wanted.

------
exDM69
Something that would be really useful: a freestanding snprintf implementation.

There are a few self-contained snprintf implementations, such as this one:
[http://www.ijs.si/software/snprintf](http://www.ijs.si/software/snprintf)

Some porting work may be required for freestanding/bare metal platforms.

~~~
drewrichardson
I've used [https://github.com/h2o/qrintf](https://github.com/h2o/qrintf)
before which replaces many snprintf usages with standard C code at compile
time

------
rzzzt
Pure64 from Return Infinity sounds like something similar for 64-bit systems
(sans C headers):
[https://github.com/ReturnInfinity/Pure64](https://github.com/ReturnInfinity/Pure64)

------
2bluesc
Should check out my bare-metal unit test project targeting microcontrollers.
Goal is to not use things like pipe()/fork()/malloc() etc.

[https://github.com/kylemanna](https://github.com/kylemanna)

~~~
2bluesc
Agrh,
[https://github.com/kylemanna/nanotest](https://github.com/kylemanna/nanotest)

------
buserror
A bit limited, as it's only for 32 bits x86, something the topic doesn't
mention.

There is no example of supported hardware, so at first glance It seems it
would only be useful on old hardware, or Soekris-like boxes...

~~~
calgoo
From his other project metioned by baruch:

"Requiring each program to include drivers for every possible hardware device
would be madness, and slow madness since device emulation is tricky and
expensive. These programs are never going to be run on bare metal anyway, so
I’m going to ignore all legacy PC devices and define the ‘fleet’ system
interface a consisting solely of virtio devices. These devices all have a
simple, standardized IO interface, so it should be no problem to build drivers
for six or eight of them into my kernel-library. I’ll offer an efficient low-
level I/O API for nonblocking DMA transfers. All the clunky, synchronous,
blocking C APIs can be implemented on top of that."

~~~
buserror
Xvisor [ [http://xhypervisor.org/](http://xhypervisor.org/) ] does that (plus
many other things) -- I do like the virtio driver layer a lot; however in the
case of Xvisor, you also get CPU virtualisation as well as IO drivers -- it's
also portable across quite a few platforms.

