I, Hacker

Hungry hungry macros 
« Back to blog

Designing a .NET Computer

Developing Renraku has led me to some interesting thoughts, not the least of which is the feasibility of a .NET computer.

Concept

Existing computers know only a few core things:

  • Move to/from memory and registers
  • Branch
  • Perform arithmetic

All the other smarts are built on top of that, leaving us with layer upon layer of complexity. What if we were to add some logic to the hardware and introduce a thin software layer on top of that?

Design

CPU

The CPU will execute raw CIL blobs and exposes hardware interfaces and interrupts. The most likely route is to keep the stack in a large on-die cache, doing a small lookahead in decoding to prevent multiple stack hits in arithmetic.

Since the CPU is going to be executing CIL directly, it's going to have to deal with object initialization, virtual method lookups, array allocation, memory manager, and many other tasks that existing systems handle purely in software. This is achieved by splitting the task between the CPU and a hypervisor.

Hypervisor

The hypervisor, like everything else, will be built completely in managed code. However, it will be a raw blob of CIL, instead of the normal PE container. The hypervisor will handle most of the high-level tasks in general, but it's up to the specific hardware manufacturer to determine what goes in the CPU and what goes in the hypervisor. The hypervisor will come up when the machine is booted, much like a BIOS. After performing hardware initialization, it will look for the bootloader.

The hypervisor provides a standardized interface to talk to drivers and memory, which are verified. In this interface, it will also provide hooks for the memory manager, allowing the OS to handle it in a nice way. Interrupts will also be hooked via this interface. The hypervisor instance will be passed to the bootloader, which then passes it on to the OS.

Bootloader

The bootloader is a standard .NET binary, and its job is simply to hand control off to the OS. Its function is effectively identical to that of a bootloader on an existing system.

OS

The OS will look very similar to existing managed OSes, with a few exceptions. Obviously, there's no need to write your own .NET implementation, and no need to write a compiler.

Because it exclusively talks through the hypervisor interface, it's possible to nest OSes as deep as you want, you simply have to expose your own mock hypervisor. You can handle resource arbitration here and run them very efficiently.

Unlike most OSes, it won't get free reign over the system. To access devices, it'll have to use verified channels with the hypervisor, to ensure that consistency is upheld. This is similar to the way that Singularity functions.

Is it a good idea?

Maybe, maybe not. I don't know how efficient a CIL chip would be or how much of the .NET framework can really be pushed onto a chip, but the core idea is really an extension of Renraku. A pure-managed system would be very powerful if done properly, but it's a pretty drastic change.

A nice middle ground would be utilizing an existing processor and using the hypervisor in place of the existing BIOS/EFI. With some code caching magic, the CIL->X compilation could be done at this level and be completely transparent to the OS. This may well be a better route than a CIL CPU, but it's tough without having more information on the hardware challenges involved with such a thing.

Happy hacking,
- Cody Brocious (Daeken)

Loading mentions Retweet

Comments (12)

Nov 19, 2009
seb said...
it is a good idea, and companies did that long ago, check wikipedia for b5000 or lisp machines
Nov 19, 2009
Cody Brocious said...
Thanks for the comment. Yea, it's certainly a good idea, but the question is where to draw the line, really. It'd be awesome to have all the traditional CLI stuff on-die, but I don't think it's practical to scale it up to compete with existing systems. I think the middle ground mentioned at the end is likely the most practical route, but I'm not sure.
Nov 19, 2009
Steve Klabnik said...
Have you seen Project Guest VM? Basically, Sun wrote a small µkernel around the JVM, so that it could be run by xen. This sounds like something that'd be pretty similar.

Personally, I think both ideas are very interesting. Eventually, I'd like to add something similar to my exokernel project, where a small libOS wrapper goes around the VM, rather than a custom kernel/hypervisor situation. The end result is kind of the same, though.

http://research.sun.com/projects/dashboard.php?id=185

Nov 19, 2009
rbanffy said...
OTOH, a .NET CPU ia very bad idea. The b5000, Lisp machines and their Smalltalk counterparts are all dead
Nov 19, 2009
Cody Brocious said...
Project Guest VM is quite cool, but it's more similar to Renraku than this. On that note, though, this is really a natural extension of the Jazelle Java acceleration on ARM processors, just a little more comprehensive.
Nov 19, 2009
Dan S. said...
I'd say not a good idea. The nice thing about 'dumb' processors with only a few simple tasks is that you have infinitely more flexibility in choosing how to handle complicated tasks.

For example: How would optimizations (like method inlining) happen? A smart software CIL compiler on a fast dumb CPU would almost certainly outperform a direct-CIL CPU... and it's upgradable.

Your middle ground is better ground. :)
-- Dan

Nov 19, 2009
Cody Brocious said...
I agree that optimization is a tough one. In a perfect world, it'd be a non-issue, but I think with the state of .NET as it is, it's actually a huge problem. CIL compilers produce notoriously bad code, relying on the JIT to make it not suck, which we wouldn't have here.

I think the only solution to that problem is to have the hypervisor handle optimization, but at that point, why even bother with the CIL CPU?

Nov 19, 2009
Rob said...
Bad idea. Microsoft is notorious for changing things. What works today won't work tomorrow. Unlike *nix where things get better while remaining true to its roots.
Nov 19, 2009
Cody Brocious said...
CIL has remained fundamentally the same from day one, with very few exceptions. The .NET framework is where changes happen, and that's in software. That said, it's obviously a concern that something big could change and it wouldn't be handled by the hardware. Another good reason to go with the middle ground.
Nov 19, 2009
Dan said...
Actually, I think having a RISC core and microcoding the rest on top of this would be an interesting approach - the core stays simple, but the CLR opcodes are much faster than if they were implemented in software.
Nov 19, 2009
bigtech said...
In theory, generating CIL at runtime is superior to precompiling. At run time the compiler can determine the best strategy for the available hardware. This could change depending on the number of and type of cores and other factors. In practice, compiling slows down an app, but as hardware gets faster and faster this is less of an issue.
Mar 01, 2010
jwmittag said...
I realize that I'm half a year late, but anyway ... I think you might be interested to look at the architecture of the Azul Java Compute Appliance (JCA) and more specifically its Vega-3 CPU. Cliff Click has given a few talks in which he describes the architecture quite well, although necessarily vague and high-level for legal reasons.

The basic difference between the Vega CPU and all the other ones (like Sun's picoJava) is that the Vega CPU is not a Java CPU. (Well, there's another difference: all the other companies are dead ... coincidence? I think not.) Basically, instead of printing out a copy of the JVM specfication and handing it to the chip designers, they printed out a copy of the JVM specification and handed it to the *compiler* designers and said "write a compiler for this, and tell the CPU designers what your dream target CPU would look like."

So, instead of building a CPU for Java, they built a CPU for compiler writers.

The CPU is a fairly standard 3-address register-based RISC CPU with about a 1 GHz clock speed and 54 cores per chip. No stack, no bytecodes in sight. The real meat of the system is memory bandwidth: while the CPU is easily outperformed by whatever you have in your pocket right now, the memory bandwidth of the system would land it in the Top 50 supercomputer list. Especially impressive is how many memory accesses can be in flight, with the CPUs still rolling: you can have several thousand cache misses without stalling a single pipeline.

Leave a comment...

 
Got an account with one of these? Login here, or just enter your comment below.
Posterous-login    twitter