Re: Why don't we have "C" machines? (was Re: [OT] Re: Should *most* memory be release back to the system?)

On 20/10/2007, M. Edward (Ed) Borasky <[e-mail]> wrote:
> 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.

Actually routers aren't that smart either. IP succeeded because it
does not need smart routers. Everybody figures that just adding more
bandwidth is easier than to make more efficient use of the current
bandwidth. The state of the art router does (beyond the bare minimum
needed to function as a router) classify the traffic into a few
priority classes and implements some logic that makes higher priority
traffic somewhat more likely to come through. Again, the only thing it
gets over memory management are some crude priorities.

>
> > 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. :)

C is akin to assembly and languages like Pascal that also use pointers
and raw memory access. The evolution went from machine code to machine
specfic assembly and then to C and other languages that try to hide
cpu and platform differences. Also from running on bare metal to
virtualisation (which strikes back today in the form of xen or vmware
that actually allow to divide memory between taks - at some expense)
single task OSes, and multitasking OSes.
To make use of C and similar languages easier, current OSes provide
reusable and shareable services and support for libraries which you
would hardly find in machine code. However, there are very few means
for managing multiple processes actually running in parallel. The
security models of current systems are a joke, there is near
non-existent resource management. It feels like were are halfway
towards multitasking OSes currently.

The RISC cpus weren't that big win. The instruction set is simpler and
more symmetric (which is what improves over time even for intel, and
the 64-bit version is way better than 32-bit from what I have heared).
Theoretically the simpler instructions could give the programmer more
control to do better optimization. But in practice the optimization
performed by the compilers is lousy on any architecture you pick, and
the simpler instructions require more memory to record the program.
Add some interesting features that expose more of the internal working
of the cpu like delayed branching or imperfect interrupts, and you get
a big mess most of the time. Yes, the compilers might improve over
time. But writing even a working compiler becomes more difficult with
these instruction sets that expose too much.

>
> > 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.

I do not see any problem with using Lisp for the system interface. You
will have to write some kernel in a lower level language to provide
the lisp runtime but then you can make the syscall interface in Lisp.
You could probably do lots of stuff that is currently in Linux also in
 Lisp.

However, Lisp is a functional language. While there is well known art
of or interpreting procedural languages in procedural languages,
functional languages in functional languages, and even functional
languages in procedural languages, I haven't heard of an interpreter
of a procedural language written in a functional language (even an
experimental, let alone useful). Since I am not an expert in the field
there might be monographies piling on the topic without me noticing.
So far I have seen only one or two articles about unsolved
difficulties with writing such interpreter.

Even if you wrote a an interpreter for Ruby, Python, and whatnot in
Lisp there is still a fundamental problem that prevents general use. C
(and C++ and assembly) code is used to get the speed nearing that of
running on the bare metal for some specialized tasks. Once you turn
everything into Lisp objects you give up that, and you cannot get it
back.

Thanks

Michal