OOP Language for OS Development

[=?ISO-8859-1?Q?Thomas_Gagn=E9?=]

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:

 

[Steven Wurster]

Why the hell would you want automatic polymorphism? There's times
when I want functions NOT to be polymorphic!

Automatic polymorphism is needed to support the Open Closed Principle.
But it can be turned off in Eiffel by declaring a routine as frozen.
Similar to final in Java, which also has automatic polymorphism.

Oh, and, nice attitude.

 

[Steven Wurster]

It's an LSP violation. Code written to deal with base classes can be
broken by new derivatives that can't accept the arguments that the
base can. This makes it hard to follow the Open Closed Principle
which says that you should try to make modules extensible without
having to change them.

Remember that it's not required for a descendant class to covariantly
redefine arguments in Eiffel. It is an option, however. And, yes,
doing it can lead to problems. In fact, we have a name for it in
Eiffel. It's called a CATcall, where CAT stands Changing Availability
or Type. That is, where a descendant routine either changes its
availability (i.e. becomes less visible) or its argument types. The
Eiffel community knows about this, and knows how to deal with it.
And, no, a compiler cannot reasonably detect where CATcalls lead to
LSP violations.

But, I'd rather use Eiffel with that 'hole' than languages that have
less power and less support for the OCP, among their other faults.

Steve

 

[Hyman Rosen]

Perhaps it's time for such a thing to be attempted.

Intel 432, Symbolics Lisp machines, probably a host of others.
Such things have been attempted, and are now consigned to the
ash heaps of history.

It should be obvious why. When you have good, fast general
purpose hardware, you can implement all sorts of cockamamie
ideas on it, and if something doesn't work out, you can try
something else. When you start implementing those ideas in
hardware and they don't work out, you're left with a useless
boat anchor.

 

[Hyman Rosen]

Your first statement is incorrect. You can decide whether it's
Derived::Foo (Derived) or Derived::Foo (Base). If you do implement the
former, you will indeed get an error. If you implement the latter, no
errors are generated.

So what's your point? All OO languages let you do the latter.
But only Eiffel allows the former, and it indeed can cause errors
at runtime. What exactly do you think is incorrect about what I said?

Could you provide a scenario where you would need to have both the base
and derived class existing in the program, and you would need to
implement Derived::Foo (Derived) overriding Base::Foo (Base)?

Beats me. Ask the Eiffel guys, since it's their theory.

Do you have any references which support your claims?

Sure. <http://www2.inf.ethz.ch/~meyer/ongoing/covariance/recast.pdf>
is a paper with Bertrand Meyer as one of the coauthors, dated 2003,
in which they are still talking about how to get compilers to do safe
covariance.

 

[Hyman Rosen]

O.K., though that will require another non-local private function?

It could, if that code was complicated enough.
It all just turns into a static boolean anyway,
either explicit or by the compiler. If Eiffel
wants to nominate it into a first-class language
feature, bully for it.

 

[Hyman Rosen]

Explain why. Don't just say it's 'hideous' without giving rationale.

If I see code which says 'f(1) + f(2)' I would be very surprised to
hear that the compiler was tossing out the f(2) and just reusing the
f(1). It's not that you can't do the same thing in C++ using statics,
but having it as a language feature just strikes me as weird. At least
Ada does it right, by only eliding calls with the same arguments for
Pure methods.

Why? You need to provide your reason for your opinion. Selective
exporting is way ahead of the public/protected/private of C++ and
Java.

It's only ahead if you think that such hiding is valuable and necessary.
I think some people have made a religion of it, and they need to stop
thinking of their code as some sacred virgin who must be defended from
the impure advances of everyone else's code, and just get the work done.
The world isn't going to end if someone gets to fiddle around with the
private bits.

 

[Hyman Rosen]

You missed the constrained generic parameter. G -> T means that G is
the generic type and it must conform to T. I don't think C++ templates
can emulate constrained generics yet, but I could be wrong.

They sort-of can, because there are ways to do the checks at compile time,
but no one really cares. Most C++ folks consider it a mistake to try to
limit generic parameters in this way, because it limits the usability of
templates for absolutely no reason. If the template happens to work for
some class that doesn't conform to T, why should it be prevented from doing
so?

C++ will never reach the expressive power of Eiffel, but then again,
you can't make an Eiffel compiler solve factorials, so maybe you win?

Yeah, whatever.

 

[Robert C. Martin]

But, I'd rather use Eiffel with that 'hole' than languages that have
less power and less support for the OCP, among their other faults.

I completely understand that point of view.



-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716

"Distinguishing between the author
and the writing is the essence of civilized debate."
-- Daniel Parker

 

[Isaac Gouy]

Intel 432, Symbolics Lisp machines, probably a host of others.
Such things have been attempted, and are now consigned to the
ash heaps of history.

Google "Smalltalk On A Risk" SOAR

 

[Cesar Rabak]

Isaac Gouy escreveu:

Google "Smalltalk On A Risk" SOAR

Perhaps more sucessful with "Smalltalk On A Risc"?

 

[=?ISO-8859-1?Q?Thomas_Gagn=E9?=]

The SOAR report was published 1984, nine years before Kay's comments in
1993. I doubt Kay was unfamiliar with SOAR and so conclude he was
disappointed in the progress hardware has made in that area.

 

[Berend de Boer]

Brian> is probably the show stopper. I'm pretty sure it is
Brian> impossible to write an entire OS completely in
Brian> Eiffel.

You can't do it in C either. You always need a bit of assember to
access the hardware.

Brian> one priority Eiffel may not be for you. SmartEiffel and
Brian> ISE Eiffel generate very efficient code, but I don't think
Brian> it meets the demands of a CPU scheduler, for example.

That's more related to multi-threading. Which Eiffel can do, and there
is even a SCOOP version of SmartEiffel.

--
Regards,

Berend.

** you're welcome to the #eiffel irc channel on irc.freenode.net

 

[Christopher Browne]

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.

 

[Christopher Browne]

Brian> is probably the show stopper. I'm pretty sure it is
Brian> impossible to write an entire OS completely in
Brian> Eiffel.

You can't do it in C either. You always need a bit of assember to
access the hardware.

The challenge in any language is that you need to build several things
that require "stepping outside the language."

- As you say, there's a need to get at assembler procedures in order
to access hardware.

- There's a need to manage context switching, to manage processes;
that likely mandates some assembler. The fact that some languages
support threading is unhelpful, because that normally requires
some "outside context."

- Ditto for memory management; the more the language integrates that,
the more difficult it is likely to be to use the language to
implement memory management.

C is pretty good for the purpose since its primitives _aren't_ much
more than a sort of "high level assembly language."

Languages that assume a garbage-collected memory management scheme are
likely to be particularly challenging ways to do this...
--
let name="cbbrowne" and tld="cbbrowne.com" in String.concat "@" [name;tld];;
http://cbbrowne.com/info/advocacy.html
"Those who doubt the importance of a convenient notation should try
writing a LISP interpreter in COBOL or doing long division with Roman
numerals." -- Hal Fulton

 

[Isaac Gouy]

Isaac Gouy escreveu:

Perhaps more sucessful with "Smalltalk On A Risc"?

More successful, yes ;-)

 

[Berend de Boer]

Christopher> The challenge in any language is that you need to
Christopher> build several things that require "stepping outside
Christopher> the language."

Christopher> - As you say, there's a need to get at assembler
Christopher> procedures in order to access hardware.

Christopher> - There's a need to manage context switching, to
Christopher> manage processes; that likely mandates some
Christopher> assembler. The fact that some languages support
Christopher> threading is unhelpful, because that normally
Christopher> requires some "outside context."

This is just bootstrapping: the initial part, Eiffel+assembler
boot into the basic kernel. The next part can be normal Eiffel with
the multi-threading support replaced/supported by what your kernel
supports.

That is what SCOOP supports anyway: installable/replaceable
multi-threading using instructions in your .ace file. That's the whole
point of SCOOP that threading is a setting, not something a programmer
should be trusted with to get always right.


Christopher> - Ditto for memory management; the more the language
Christopher> integrates that, the more difficult it is likely to
Christopher> be to use the language to implement memory
Christopher> management.

You just compile in a different gc.


Christopher> C is pretty good for the purpose since its primitives
Christopher> _aren't_ much more than a sort of "high level
Christopher> assembly language."

Yep, my Linux system locks up now and then when just using mplayer.

--
Regards,

Berend.

** you're welcome to the #eiffel irc channel on irc.freenode.net

 

[Philippe Ribet]

Eiffel Cons (related to OSes):
There is no turnkey Eiffel compiler for you to use for operating
systems. All the current compilers are system-oriented, that is, they
generate systems, which for example have command-line arguments and
garbage collectors. Unless I'm mistaken this is probably the show
stopper.

Using SmartEiffel should not be a problem. -no_main option may help.
The garbage collector can be turned off. Then the memory job is limited
to se_malloc/se_realloc.

I'm pretty sure it is impossible to write an entire OS completely in
Eiffel. Number one reason, Eiffel has no method for declaring
interrupt handlers. The good news is that Eiffel integrates with other
languages easily (C for example which has an interrupt keyword).
If efficiency is your number one priority Eiffel may not be for you.
SmartEiffel and ISE Eiffel generate very efficient code, but I don't
think it meets the demands of a CPU scheduler, for example.

I did some testing on computationnal code (matix multiplication). Code
generated by SmartEiffel had exactly the same performance as the same C
program. But never forget, each time you need extreme performance or
very specific instructions, you can use C code (inline or external
function call). This mean you can use assembler too when you really need
(context swith, hardware access).

--
Philippe Ribet



The README file said
"Requires Windows 95, NT 4.0, or better."
So... I installed it on Linux!

 

[Brian_Heilig]

Philippe Ribet...

Using SmartEiffel should not be a problem. -no_main option may help.
The garbage collector can be turned off. Then the memory job is limited
to se_malloc/se_realloc.

So you could, for example, write the really low level stuff in
assembly, write the bulk of the OS in Eiffel, and then use CECIL to
bridge the two? What I'm asking is, if you were writing an OS in
Eiffel, is that what you might do?

If that's all it takes then I highly recommend Eiffel for OS
development. The more I think about it the better it sounds.

Brian

 

[Brian_Heilig]

JKop:

Why the hell would you want automatic polymorphism? There's times
when I want functions NOT to be polymorphic!

It's not FORCED polymorphism. The bottom line is that with automatic
polymorphism you get BETTER performance, because you get polymorphism
only when you need it. Also, as Steve said, it allows you to override
any feature you want without having to put `vitrual' before that
feature's name in the parent.

Brian