The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

The OS as hardware

Subtitle: Wacky Idea # 1154327

Imagine these two futuristics scenarios:

1. Let's say that Moore's law has hit the wall, and the laws of physics have prevailed.  Hardware manufacturers (Intel, AMD, etc.) are looking for that "next big thing".

2. Linux development has continued on, and the kernel is considered rock solid.

Would it be feasible to create a chip (or set of chips) that functioned as the OS?

Here's my wacky idea.  Take the software for the OS and model it as a (gigantic) state machine.  Then, use that state machine as the design for the 'OS chip'.

The OS would no longer be the hardware/software interface.  Instead, compilers would compile programs to talk directly to the OS chip.  The OS chip would in turn be the interface to all the other hardware.

For minor OS revision changes, firmware updates would be released, and for major OS revisions, new chipsets could be purchased and installed.

Is this idea feasible, or am I living in Dreamsville, Population: me.
Yet another anon
Friday, September 03, 2004

correct me if I'm wrong, but isn't Firmware just Software, too. Except it resides in a memory that is not deleted if you shut down your machine.

So, if you are able to do Firmware upgrades to the OS, the OS still is software. Like the BIOS is software, not hardware.

The idea of placing the OS into ROM instead of loading it from a disk actually is an old one. The early computers - like Commodore 64 - did it and each mobile phone does it, too. It is suitable in this cases, because the environment is well known, which does not hold on desktop computers. Just thing about how fast new hardware is developed and has to be supported by the OS.
Friday, September 03, 2004
Interesting question...

I think there were plans to do this with JAVA, I seem to remenber hearing about 'JAVA on a chip' a few years ago, promising a dramatic increase in JVM speed.

It doesn't seem to have held its promises, at least I've not heard from it again for some time, so I assume it was a failure?

It sounds like a good idea on paper, though. But I think it would be more a "framework as hardware" or "APIs as hardware", than the OS which is probably too complex?...
can't find a nice nickname!
Friday, September 03, 2004
You would sort have a Mac then, to some extent.  Hardware and OS coupled tightly. Linux (or even Windows) would not be where it is today with out the ability to run on such a wide variety of platforms.  We have Moore's law because we have competion.

If you ask me, Moore's law will continue correct for a very long time.  The shame is that software is not part of Moore's law.
Bill Rushmore Send private email
Friday, September 03, 2004
But is the OS after all anything more than an API for "operating" the hardware?  It's an abstraction layer, so that a text editor doesn't have to worry about 1's and 0's and whether you're saving to a Seagate or Western Digital and whether your mouse is USB or PS/2 and...
As to the complexity of the OS, a) ever looked at even a high-level diagram of what's already going on inside chip architecture?  And b) if you break out hardware-specific drivers into loadable modules, seems to me the core kernel itself can be pretty lean.
Joel Fouse Send private email
Friday, September 03, 2004
>If you ask me, Moore's law will continue correct for a very long time.  The shame is that software is not part of Moore's law.

Don't you count the fact that software will bloat to consume any extra capacity almost as soon as that capacity is available?  ;^)
Friday, September 03, 2004
>>  But is the OS after all anything more than an API for "operating" the hardware?

An OS is an abstraction layer and a set of applications.
For instance WinXP is an abstraction layer, plus a  n explorer, a task manager, a notepad and a solitaire ... (and much more of course).

I can see the abstraction layer wired on the chip,  but I think the apps wouldn't be... they might be present as bios or firmware thought, giving an OS on a chip, but for me there is a distinction.. only a low level layer would be hardwired.
can't find a nice nickname!
Friday, September 03, 2004
Read up on lisp machines. They were CPUs that ran lisp code in hardware, highly optimized for lisp.

The trouble was that the market for them was so small that they didn't have the economies of scale that the big chip makers had, so within a year or two a Motorola 68000 could run lisp code a lot faster than a lisp machine.
Joel Spolsky Send private email
Friday, September 03, 2004
The problem is getting the hardware guys to keep the API standard. Competition would lead to some chip maker deciding to "extend" the API and then suddenly they are all off to the races with their own special API functions.

Next thing you know we'll be talking about how the abstraction layer should be part of the software and not in the hands of the hardware guys... :)
Marc Send private email
Friday, September 03, 2004
I'm thinking about what Joel was saying about the lisp machines (interesting stuff, thanks!).

From that perspective, think about the interpreter part of Java somehow being incorporated into processors.

What sense would that have really made? On an extremely simplified level, they would just be adding more transistors to a chip.

Why complicate the design and such instead of simply developing faster chips to run not only Java, but everything faster?

On a vaguely similar note, someone has written some software that lets you tap into your graphics card processor directly and use it sort of as if you had a dual-processor machine. I'll post a link later if I think to.
Friday, September 03, 2004
Acorn computers had their operating system (RISC OS) stored in ROM. They were 32 bit ARM-based machines that were heavily used in British schools well into the late 90s and are still being produced now but not used in such numbers. The OS sported a very nice WIMP GUI interface natively that was all stored in a 4 Mb ROM.

A lot of the OS was stored in what are called relocatable modules (similar idea to DLLs) that are located on ROM. By loading a new version of a module from disk into RAM it would replace the older version in ROM instantly (and actually run a bit quicker as a result). Significant upgrades to the OS still have to be made by replacing the ROMs.

mutabled Send private email
Saturday, September 04, 2004
For moving functionality from software to hardware, check out the IBM z big iron machines. There you have a sort-of operating system in "hardware" (it's not really hardware of course, just as all hard drives runs lots of small programs, but it's abstracted away with hardware), which does all the partitioning of the machine etc.

Those partitions, in turn, run the operating system and the software you want. Apparently there must be some emulation going on as well because you're supposed to be able to run almost 40 year old code with no problems. It's all very neat, but a bit hard to read about and understand because everything is called something else than you're used to.
Jonas B.
Saturday, September 04, 2004
Java CPUs fell out of favor because they could not compete with a mainstream CPU and a well-tuned JIT engine.

A low-volume part such as a Java CPU will be designed using ASIC methodologies and fabricated on mainstream ASIC processes and will attain clock speeds up to 300 MHz or so.  In contrast, dedicated CPUs are designed using full-custom methodologies and fabricated on special-purpose processes and achieve low-GHz speeds.

Data point: my Sony Clie handheld uses a 200 MHz ARM, and outruns a 33 MHz 68000.  No mean feat considering that the ARM must emulate the 68K.  The Java bytecode is considerably simpler to emulate.
David Jones Send private email
Saturday, September 04, 2004

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz