
BareMetal OS: A 64-bit Operating System in only 16KiB - iseyler
http://blog.returninfinity.com/2010/09/baremetal-os-v049-and-baremetal-node.html
======
tankenmate
Wow, from the queue presentation this OS looks even less usable than DOS (MS
aka Q). Why would the CLI terminate when it runs a programme? How do you run
more than one programme at once? If each core polls the run queue does that
mean that it busy cycles when there is no more work to do? Won't this waste
energy? (A sin in the HPC world). Does it do the same for IO? IO request
completion on a slow and/or busy disk could take as long as 50ms, for a 2.5GHz
CPU for example this is 125 million clock cycles. Will the CPU busy cycle this
as well?

If you want a simple OS that fits a lot into a small space, why not get a copy
of the Lions' Commentary and translate the edition 6 kernel into asm. If you
wanted to go gung ho you could add a simple BKL, demand paging and a network
stack to complete the job. You could probably do all the above and keep it
somewhere close to 20,000 lines of assembly (excluding drivers).

If you are looking for an education doing the above will probably do you just
as good a job as trying from scratch.

Lions' Commentary on UNIX 6th Edition, with Source Code
[http://en.wikipedia.org/wiki/Lions%27_Commentary_on_UNIX_6th...](http://en.wikipedia.org/wiki/Lions%27_Commentary_on_UNIX_6th_Edition,_with_Source_Code)

The Art of Computer Programming
<http://en.wikipedia.org/wiki/The_Art_of_Computer_Programming>

~~~
onan_barbarian
TAOCP and the Lion's commentary? Edition 6 kernel into asm? Why?

You're working hard to sound old-school, but these are just random allusions.
TAOCP is not especially relevant to OS programming, and translating _all_ of
an OS into asm to make it "fit a lot into a small space" is just... plain...
stupid...

You will make the code smaller (as compared to gcc -Os) in a few places; you
will likely give yourself a hernia maintaining it, and you are likely to get
considerably worse performance than a decent compiler will.

~~~
pjscott
To expand on that: it's fun to take a look at the assembly code "gcc -O3"
produces. It's absolutely wild: even after staring at it for a while, I often
have no idea what clever tricks gcc used to turn the C code into that assembly
code. It does a better job of making fast, compact code than I suspect I ever
could.

There was a time when C compilers generated crappy assembly code, because that
was easy for the compiler writers. That time is long past, with exceptions for
a very few situations where the compiler misses a trick that a human can do.

~~~
onan_barbarian
Well, sometimes it's fun. Other times it's utterly horrible. gcc doesn't
always do a wonderful job and the maintainers sometimes just don't seem to
care - induction variable optimizations and gcse were broken in 4.2 and 4.3
and the issue was left unfixed, with clear examples of obvious FAIL on simple
and performance-critical inner loops.

However, this doesn't apply so much to OS code, which doesn't have nearly as
much opportunity for micro-architectural shenanigans either way. Typically
something like -Os does a good job of handling operating system style code.

Hand-coding OS asm remains a fine example of pointless tedium for the most
part. There are clear places where you absolutely need asm, of course, but
writing stuff in asm that can be perfectly well done in C is like cleaning out
the barracks room bathroom with a toothbrush.

This was one of the early innovations of UNIX (high level language use), so
there's something wildly anachronistic about this guy's suggestion. It's like
suggesting that you rebuild grandpa's Studebaker so that it can be drawn by a
team of horses.

------
mathgladiator
Keep it up, I love new OSes.

My dream is to write a cloud programming language that compiles high level
code to a low-level kernel and deploys. I abhor waste, so efforts like this
are a great start. I look forward to more!

~~~
pedrocr
> My dream is to write a cloud programming language that compiles high level
> code to a low-level kernel and deploys.

I'm curious as to what you want to gain from that compared to running a custom
compiled Linux kernel with your program as init or as the only running
process.

~~~
mathgladiator
Nothing from an engineering standpoint.

<http://en.wikipedia.org/wiki/Art_for_art%27s_sake>

------
junkbit
The spin-off Pure64 looks very interesting. It looks like they have factored
out the code for getting up and running with your own project:

"The loader gets the computer into a full 64-bit state with no legacy
compatibility layers and also enables all available CPU Cores in the
computer."

"Two very simple kernels are included to get you started with your new 64-bit
OS (One written in Assembly, the other in C)."

~~~
wmf
There seems to be some "64-bit" buzzwordism going on here. There's nothing
special about 64-bit; it's just a different processor mode. Writing 64-bit
code is no different than 32-bit.

~~~
zokier
AMD64 also included a lot more registers, and has some extensions to the
instruction set. It also makes a baseline for other features like SSE, as all
CPU:s supporting AMD64 are relatively modern. Also having larger address space
to work with may affect some design decisions.

So while you can write 64-bit code just like 32-bit code, it's bit like saying
that writing c++ is no different than writing c.

------
shawndumas
<http://www.returninfinity.com/baremetal.html>

------
dryicerx
This reminds me of MenuetOS (<http://www.menuetos.net>), although a bit larger
BareMetal OS, still manages to cram in a unholy amount of functionality in to
a couple of megs.

~~~
swolchok
FWIW, I found a local privilege escalation vulnerability (arguably just a bug
allowing apps to trash the kernel, since it's single-user anyway) in Menuet32,
and I'm not optimistic about the network stack. I would have expected ping of
death to work, but it doesn't even seem to support IP packet fragmentation.

These throwback OSes are cute, but there would be hell to pay if they ever
took off.

------
cschneid
Other than the academic nerdiness of minimal OSs, what is this good for?

Do modern OSs cause too much overhead for certain operations?

~~~
CapitalistCartr
They cause too much overhead for teaching. A minimal OS is a great way to show
how one works, what the essentials are, and even what weaknesses it has.

~~~
pjscott
It's amazing, when you look at a simple operating system like TinyOS, just how
simple some of the things are. (Once you start actually hacking on the OS
code, you realize that they're also very finnicky and easy to mess up if you
don't know what you're doing. And hard to debug.)

------
JoeAltmaier
Could be useful if it did something new - support virtual apps, manage
restartable/persistent state processes, something. Just another
thread/memory/interrupt kernel? Why?

~~~
zokier
I think the point here is being minimalism, and being a starting point to
build on those features you mention.

------
orblivion
So is this like the demoscene stuff or is there a practical use for it?

~~~
runjake
I read the link in the article, so I'll just paste what it says:

* High Performance Computing - Act as the base OS for a HPC cluster node. Running advanced computation workloads is ideal for a mono-tasking Operating System.

* Embedded Applications - Provide a platform for embedded applications running on commodity x86-64 hardware.

* Education - Provide an environment for learning and experimenting with programming in x86-64 Assembly as well as Operating System fundamentals.

~~~
_delirium
For the first use, it seems like it'd be nice if there were some way it could
reuse existing hardware-compatibility work done on projects like the Linux
kernel or the BSD kernels. Even if you want a single-tasking system with
little in the way of OS services, you still usually don't want to be debugging
the quirks of every hardware device, or writing your own driver every time you
get a machine with a new SATA controller or NIC.

------
antidaily
Can you play Doom on it?

