Hey all,

So I've just thought of the craziest idea... what if you programmed an os entirely in vhdl? Obviously it could only ever run one os since it would be directly programmed in hardware but that single os would experience a huge improvement in speed since it wouldn't be to be "translated" into c and then assembly and the microcode and then micro ops. Thoughts?

Something like the Intel iAPX 432?

Mike B.

Well... yes and no. Of course it had no real os. But keep in mind, it came out a year before the 8086. Yes it had poor performance compared even to contemporary processors of the day. But, an application running on it (stretching your comparison a little), if you pretend it had an os in hardware, would be the equivalent of being programed directly in assembly. And I guarantee you, any program made in iapx32 assembly would be faster than any program running on an 8086 dos unikernel.

Edit: Getting back to my idea, an os in vhdl could potentially even be asynchronous. And as for the iapx32, half its problems could also be easily solved today without 20 man-years of work. And an os like sel4, being formally verified, could nullify the issue of bugs in the os requiring an update to the entire fpga.

> a year before
Hmm, not by release date: 8086 is from 1978, '432 is 1981.
I see Wikipedia says
"Intel's 432 project started in 1975, a year after the 8-bit Intel 8080 was completed and a year before their 16-bit 8086 project began"
but dating a project from design start doesn't seem right to me - the 432 as shipped was very complex and could not have been economic in the 70s.

BigEd,

You're right, my mistake.

But I still think the iapx32's failure was mostly unrelated to its mega-cisc complexity. By that logic, modern x64 cpus must be even slower. And I dont think an 8086 even at a 7 nm process would run half as many fps on starcraft/whatever as a p3

And although all this is still very off-topic, the benchmarks showing it to be slower (1/4 speed) were written in ada running on an os written in ada running on the iapx, while the x86 benchmarks were all c down to the os. And the ada compiler was apparently pretty inefficient, and the entire cpu was cut in half and put on 2 different chips. Not to mention amd bulldozer-scale design errors. But on equal footing, I also still think those benchmarks written in iapx asm would be much faster than the same benchmarks on dos on the 8086, since I'm pretty sure dos had a higher overhead than just 3 out of every 4 instructions. I could be wrong again though.

Probably slowed down by all that bubble memory it was using too...

I'm struggling to imagine what it would mean to put tens of thousands of lines of software complexity into hardware, if not expressing it as a CPU and code to operate on. My feeling is that it would be horribly slow, because casting something as enormous as an OS into the form of a state machine would make it very large indeed. Hardware is only fast when it has appropriate structure. If you look at the various 6502 implementations for FPGA, you'll see a wide variation in speed and gate count.

It's an interesting idea. A lot of work to find out if it's practical or not.

The following maybe based more on a gut feel than actual factual evidence (one would actually have to build a hardware OS and test it to known for sure), But,
I looked briefly at implementing some parts of an OS in hardware. I took part of a simple OS and implemented several routines in Verilog. For instance task scheduling. Operating list insertions and deletions. There might be some performance gains for a really simple OS as things can be done in parallel that have to be done serially with software. Some of the code in my implementation replaced dozens of lines of software with single cycle execution in hardware. But the operating system shouldn't be a big consumer of CPU cycles. So making it in hardware likely wouldn't increase performance very much if at all. Putting a modern operating system in hardware probably isn't practical. There are many components to an operating system and the hardware required to implement it would be large and therefore slow down the clock cycle time. It would likely slow everything down while improving the OS performance only marginally.

_________________
http://www.finitron.ca

You've just reminded me Rob, together with the recent mention of the transputer by rwiker in the thread over here, that the transputer has a task scheduler built in. Very important, with the fine grain of interprocess communication on that machine, much of which communication will block.

Hardware support has always been of interest to the dynamic languages. Support for Garbage Colleciton Write Barriers, data tagging, etc.

I think it would be interesting to build up the Smalltalk VM in to hardware. Get a Squeak or Pharo runtime going on an FPGA much like the Oberon folks did.

> Smalltalk VM in hardware
I had a look - best I could find was the Z machine in hardware.
https://github.com/charcole/Z3
(And some opinions that it's difficult to get a performance win, given the speed of FPGAs versus the speed of well-optimised custom silicon.)

Dude, that is awesome. I'm not interested in porting Linux or windows to vhdl lol... but what about the l4 microkernel? The sel4 microkernel is the os I want to use, and it only takes up 10.2 kloc. It is also literally bug-free .

It is also completely written in C, with only 500 loc in x86/arm assembly. So I could just use, theoretically, a c-to-vhdl/verilog translator and get the necessary Verilog or vhdl in ten lines of shell scripts.

And considering that there are verilog designs that take up far more than just 10-15 kloc, it seems that it is completely possible to make a real os in Verilog or vhdl.