Re: OOP Language for OS Development

["Thomas Gagné" <tgagne@wide-open-west.com>]

Back to the original question...

I would expect there's conflicting demands on the operating system and 
consequently the language it's written in.  It is presumably responsible 
for interfacing directly with hardware, and must provide suitable 
abstractions for anything that might be attached to it.

At the same time, the operating system must play host to applications 
written for it, and it doesn't make sense to me that the OS should place 
restrictions on application languages--though it could turn the tables.

In today's popular operating systems the lower-level a language you are 
the greater advantage you have over higher-level languages.  If the 
operating system were written in an OOL that normally requires a virtual 
machine then that VM would be more native (or natural, perhaps) to other 
OOLs that could use the same VM.  Low level languages would have to run 
inside their own VM because the low-level operations might not be 
available to them.  Imagine writing a C program that didn't run as fast 
as a Java program because the C program had to run inside a VM on top 
the OS!

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.  Imagine if such a thing 
were successful then chip manufacturers could begin developing chips to 
make the VM run faster as was suggested by Alan Kay years ago: 
<http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html#coda>

    "Hardware is really just software crystallized early. It is there to
    make program schemes run as efficiently as possible. But far too
    often the hardware has been presented as a given and it is up to
    software designers to make it appear reasonable. This has caused
    low-level techniques and excessive optimization to hold back
    progress in program design. As Bob Barton used to say: "Systems
    programmers are high priests of a low cult."

    "One way to think about progress in software is that a lot of it has
    been about finding ways to /late-bind/, then waging campaigns to
    convince manufacturers to build the ideas into hardware. Early
    hardware had wired programs and parameters; random access memory was
    a scheme to late-bind them. Looping and indexing used to be done by
    address modification in storage; index registers were a way to
    late-bind. Over the years software designers have found ways to
    late-bind the locations of computations--this led to base/bounds
    registers, segment relocation, page MMUs, migratory processes, and
    so forth. Time-sharing was held back for years because it was
    "inefficient"-- but the manufacturers wouldn't put MMUs on the
    machines, universities had to do it themselves! Recursion late-binds
    parameters to procedures, but it took years to get even rudimentary
    stack mechanisms into CPUs. Most machines still have no support for
    dynamic allocation and garbage collection and so forth. In short,
    most hardware designs today are just re-optimizations of moribund
    architectures."

Perhaps it's time for such a thing to be attempted.  If done well enough 
it could be the proof that late-binding is something much-needed in 
operating system and not just their applications.



     wrote:

>Hi All,
>I am developing an object oriented OS code-named "ikbocs".
>1) What are the pros and cons of the following languages interms of  
>Effectiveness on System Programming, Object Orientedness etc ?
>(Simula, Smalltalk, Modula-3, Eiffel, Sather, C++)
>I suppose Java is not suitable for Sys. Programming.
>
>2) Which OOP language would be better for OS development?
>
>TIA
>KingIshu
>  
>

-- 
.tom
remove email address' dashes for replies
opensource middleware at <http://isectd.sourceforge.net>
<http://gagne.homedns.org/~tgagne/>