Re: OOP Language for OS Development

[Christopher Browne <cbbrowne@acm.org>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2954 bytes --]

In the last exciting episode, Thomas Gagn� <tgagne@wide-open-west.com> wrote:
> Of course, that may not be required.  But let's look at two languages
> on opposite sides of the spectrum--C and Smalltalk.
>
> If the OS was written in Smalltalk then its imaginable the natural
> instructions might be Smalltalk's.  Would C programs be compiled
> into Smalltalk opcodes?  That would be interesting.

This phenomenon was actually seen with Symbolics Lisp Machines.

They were "natively" programmed in Lisp (something fairly close to
Common Lisp), and the hardware was specifically attuned to that.

There was indeed a C compiler for Symbolics; it generated "Lisp
Machine assembly language," which is pretty much equivalent to your
suggestion of C being compiled into Smalltalk opcodes.

This form of C was certainly different from what is traditional; there
was no notion of "numeric" pointers; it used Lisp 'pairs' to represent
pointers.  That doesn't break C, although it doubtless breaks code
that assumes that pointers are objects that may be manipulated
arithmetically...

What was discovered was that it cost _WAY_ too much to keep
redesigning these CPUs every other year.  It is certainly
spectacularly costly for AMD and Intel to create each successive
generation of their chips, but they can amortize the costs across many
millions of chips.  Lisp Machines didn't have the quantities of sales.

Symbolics stopped designing hardware; they wrote some Alpha microcode
to let them get an efficient pseudo-instruction set on Alpha
processors, which was a sound idea, but they faded into oblivion for
other reasons.

It seems pretty clear to me that the Intel Itanium "EEPIC" approach,
which requires even smarter static compilation, is likely to be a vast
mistake in the long run as far as general purpose use is concerned.
It'll be nice stuff if you deploy all your apps in source code form so
that you can recompile in the target environment, to get a static
optimum, but it's terrible if the goal is to deploy precompiled
binaries on a diverse set of hosts.

But to get some _actual improvements_ to architectures that are usable
for OSes strikes me as troublesome.  All the 'popular' systems these
days are based on C (or something vanishingly nearby), and it would
take jumping to an implementation language as esoteric as Smalltalk,
Lisp, or ML in order to get an OS able to make much real advantage out
of special instructions.

And the result is a system SO different that you likely have to start
over from scratch in terms of building system utilities, compilers,
data storage, and such; a big enough project to daunt most would-be
participants.  It's a lot easier to grab a Linux/BSD kernel and do
something in a Unix-like userspace.
-- 
If this was helpful, <http://svcs.affero.net/rm.php?r=cbbrowne> rate me
http://www3.sympatico.ca/cbbrowne/advocacy.html
Lisp Users:
Due to the holiday next Monday, there will be no garbage collection.