From: "M. Edward (Ed) Borasky" <znmeb@...>
Date: 2007-10-20T12:55:27+09:00
Subject: Why don't we have "C" machines? (was Re: [OT] Re: Should *most* memory be release back to the system?)

Michal Suchanek wrote:
> Well, the memory subsystem is quite underdeveloped on the "general
> purpose" OSes. You normally do not get resource accounting unless you
> do realtime or some specialized OS but you at least get priorities for
> cpu time. Nothing like that for memory. It is all just best effort,
> distributed more or less proportionally to the amount of pages the
> process has touched recently, and when it runs out something randomly
> breaks.

You're right ... memory management technology (hardware or OS) hasn't 
improved substantially since the days of Peter Denning and System\360. 
:) Part of that is due to the fact that the equations necessary to come 
to some reasonable conclusions about alternatives are ghastly. They're 
much more difficult to deal with than those that govern networking, for 
example, which is why routers are so smart these days and memory 
management is stuck in a time warp.

> I cannot imagine what else you can do when you want an OS that runs
> pretty much all languages. All that the OS can do is hand out pages,
> and only the language runtime can manage the data inside those pages.
> Unless you tailor the OS to one specific language or virtual machine
> you cannot get anything more.

But that's pretty much what we have now, that one specific language 
being C. There was a time when operating systems and compilers were 
written either in assembler or other "system programming" languages like 
Bliss. But now most operating systems are written in C, most compilers 
and interpreters are written in C, and it's only end-user applications 
that tend to be written in all the other languages. So really, you get 
"pretty much all languages" by writing their compilers or interpreters 
in C.

So you could tailor the OS (and hardware) to C. (That's actually where 
the "RISC revolution" was headed, until Intel found a way to 
out-manufacture the RISC chip vendors.) But that's not what has 
happened. Instead, the OS acts as a kind of "middleware" between 
compilers and interpreters and the hardware, and there's another layer 
of middleware inside the chip between the OS and a "RISC core" that 
actually does the arithmetic and string operations. The Intel Mac was 
only the last nail in the coffin of RISC. :)

> Well, that's where you get if you manage the language objects in the
> OS (assuming that a lisp machine is the thing where you basically run
> lisp runtime on the bare metal). It's perfectly integrated but you
> lose the ability to run other languages easily because you have to map
> them somehow to your chosen language. For some that are similar enough
> it might be easy, for others difficult, and for some (near)
> impossible.

Actually, you can write compilers for other languages on Lisp machines, 
and you can write an operating system in Lisp too. I don't know how well 
suited Lisp is to running an OS, but it's an excellent language for 
writing compilers and interpreters. But we don't have Lisp machines 
today for the same reason we don't have many RISC machines today -- the 
alternatives had more powerful marketing and manufacturing.