Writing an OS for PC
David Logan
73114.3621@compuserve.com
30 May 95 10:05:10 EDT
-----BEGIN PGP SIGNED MESSAGE-----
Francois -
I tried to send this reply to the internet address I recieved from your last
reply. It was returned, and the text in it's entirety is here. I'm going to
send a 2nd reply to this address.
David Logan
==============================================================================
Sender: mailer-daemon@compuserve.com
Received: from localhost by arl-img-4.compuserve.com (8.6.10/5.950515)
id WAA20467; Mon, 29 May 1995 22:52:18 -0400
Date: Mon, 29 May 1995 22:52:18 -0400
From: Mail Delivery Subsystem <MAILER-DAEMON@compuserve.com>
Subject: Returned mail: Host unknown (Name server: samaris.ens.fr: host not found)
Message-Id: <199505300252.WAA20467@arl-img-4.compuserve.com>
To: 73114.3621@compuserve.com
The original message was received at Mon, 29 May 1995 22:52:17 -0400
from mailgate@localhost
----- The following addresses had delivery problems -----
root@samaris.ens.fr (unrecoverable error)
----- Transcript of session follows -----
550 root@samaris.ens.fr... Host unknown (Name server: samaris.ens.fr: host not found)
----- Original message follows -----
Received: by arl-img-4.compuserve.com (8.6.10/5.950515)
id WAA20462; Mon, 29 May 1995 22:52:17 -0400
Date: 29 May 95 22:49:54 EDT
From: David Logan <73114.3621@compuserve.com>
To: System administrator <root@Samaris.ens.fr>
Subject: Writing an OS for PC
Message-ID: <950530024954_73114.3621_EHJ47-1@CompuServe.COM>
- -----BEGIN PGP SIGNED MESSAGE-----
Francois -
You have some interesting concepts, some of which I'd like to ask a few more
questions about. The first thing that comes to mind after reading your letter
is that it seem you are attempting to create a very strictly controlled
environment. Hmmm. I don't know about that. I've always found difficulty in
very controlled environments. As a programmer, I always, but always, find
something that I need to do where there is no way (or support). But anyway,
let's go on:
>> Preemption is made necessary by the complete unsecurity that has
>> deep roots in traditional OS design. But when possible (most of the
>> time), cooperation yields *far* better performance. In TUNES, we will
>> provide the required security for cooperation
What is "required security"? Without preemption, you have no way of keeping
a task from locking up the entire system. You also have no way of executing
work with any type of priority scheme, as far as I can tell, unless you have
some OS implementation ideas I haven't grasped. I do agree that cooperation
can improve performance. However, after dealing with Windows for so long, I am
really tired of "cooperation", where one task decides he's the only one that
gets to make the CP wait for god knows how long.
>> Of course, this security is just impossible to achieve using C [well,
>> not completely impossible; but then, C would be only a very heavy
>> burden, and would lose *all* its advantages: existing libraries and
>> compilers]. Which is why TUNES refuses C as a standard system
>> language.
I'm not an advocate or an opposite of C. I use any and all programming
languages. However, I don't really understand how anything is impossible in C,
nor how C code could be a heavy burden on anything, esp. with a good optimizer.
(Could be kinda bias, though, I prefer assembler to all languages). So what
language DO you plan on using? I can't think of anything better than C than
assembler.
>> Well, sure the implementation on 32-bit computers like intel PCs
>> should be 32-bit. But TUNES intends to allow dynamic distribution on
>> heterogeneous platforms with different word size (e.g. 8, 16, 20, 32,
>> 64 or 128 bits). Thus 32 bit should not be hardwired anywhere in the
>> system, be purely implementation dependent, and should not interfere
>> with dynamic code migration.
Obviously, you do plan on using a high-level language that supports porting.
Again, one of the things that I don't understand is how you are going to
prevent dependencies on your word size. From the user perspective, it's much
easier. From the OS point of view, not depending on the hardware would be
virtually impossible, wouldn't it?
>> TUNES will provide fine grain at all levels: you can determine
>> exactly what modules you have. A stripped specialized system should
>> fit the small ROM of some embedded micro-controller, while a full
>> featured one could take advantage of thousands gigs of distributed
>> shared memory.
You are aware that recapturing efficiencies in other areas are going to be
spent on this arena? One of the reasons that I am choosing to avoid a message
based system is due to the fact that zillions of messages, function calls upon
function calls, strict interfaces to millions of little functions consumes vast
amounts of resources. "Fine grain" sounds like it will take a significant
amount of resource to get from the 1st user call, all the way down and back
again, depending on what was requested of it. I guess "fine grain" is
relative, though, and perhaps I don't understand your breaking points.
>> Now, with existing software tools, writing usable error recovery code
>> is *very* difficult.
With the MVS operating system, error recovery code is quite easy to write and
implement. The OS calls the current error recovery procedure, and keeps
cascading through previously catalogued error recovery procedures until one
handles it to the point it wants the OS to "retry" the user's process. The
funnest part is actually figuring out what to do in various error conditions.
>> Higher-order programming should allow programmable debug code
>> generation from annotated sources.
Programmable debug code generation? What's that? Is this the same stuff
that's written into Borlands C and ASM programs when you request debug support?
This is great for user programs, but often impossible for system-oriented
programs/tasks.
>> Debugging is needed at source level. A language that requires debugging
>> is lame. A language that doesn't allow debugging is lamer even.
I don't disagree with the need for source-level debugging. It is valuable
beyond ... Other things are required as well, though. No matter how well
anything is written, things end up in endless loops, memory does get trashed,
etc. Source level debugging *only* is simply not enough for all problems. The
statement about a language that requires debugging is interesting. How in the
world are you ever going to prevent logic errors? Errors like moving a count
to a pointer, a pointer to a count, and be-bopping through an array? Such a
high-level language where the statement "DO IT." generates and runs an entire
program (exaggeration, of course, but not sarcasm)?
>> Firstly, let's make it clear that all PC specificities should not
>> modify in any way the user-visible specifications of the system. Only
>> the system and compiler back-end implementors should /need/ know
>> them. TUNES will be as portable as can be. Once portable code is
>> running, everyone is free to use the niftiest trick to make one's
>> modules faster and smaller on one's computer.
I like portability. Everyone likes portability. It keeps people from having
to write 15 identical programs in 15 different ways. However, I don't believe
that PC specificities (nice word) should be shut out. A good programmer who
needs the thoroughput can always find the best way to do that with the hardware
they are on, as long as the capability is there. The point, I guess, is that I
always want the capability to use environment-dependent code if I choose. I
may choose to write some small functions this way if it can improve my process
X%, with the rest of the product calling the small functions. In this way, I
can maximize my program, and minimize the rewrite requirements in the case of a
port.
>> Of course, as few selectors as possible should be static, but more
>> than two may be useful, be it just to allow use of code in multiple
>> priviledge rings, return to real or v86 mode, etc.
Depending on the efficiency requirements, I suppose. My method is to have
two static selectors. The first selector is a data pointer to itself (both GDT
and all LDTs). The second is the OS virtual memory pool, where everything else
in the world is anchored to, somehow, someway.
>> Sure, we shall take the most out of the hardware capabilities. Now,
>> I can't see why the programmer would want to interfere with such
>> low-level unportable things. We shall first limit all that as much as
>> possible. Later modules can implement their own abstractions and
>> management of these.
Basically to report. Report on tasks, users, memory, device characteristics
or status, etc. In these cases, if the memory aquired by the OS to maintain
this information is DPL 0, it requires a task to go DPL 0 to get it. This is
just one more task that can kill the OS. If you make as much as possible DPL
3, write-protected, you have the ability to minimize OS stability. You even
have the capability of running much of the OS itself DPL 3 to prevent it from
munching itself. It only goes DPL 0 when it must perform something requiring
the privilege.
>> Tasks are some coarse-grained abstraction, that only introduce
>> overhead with no gain. Only emulation boxes and unsafe code need run
>> in isolated address space.
Please don't take offense, but I think this statement is ridiculous. The
first thing that I'd say is: unsafe code = EVERYTHING. Emulation boxes, of
course. But the first thing that comes to mind is that every task has the
capability to use a 4GB address space. If you don't task, then ALL tasks can
only share 1 4GB. Back to the days when people didn't know what virtual
address spaces were, almost. Also, I believe there is lots of gain. It
utilizes the hardwares capability to execute other tasks when the current task
cannot execute, instead of having the OS software have to try to perform a
state switch. This is what DOS has done for years with TSR's.
>> In TUNES, there is no such thing as "system call".
This is what I think I'm getting, but still wondering about. It sound like
you are trying to create a product where user tasks and system tasks alike hold
hands, and dance nicely together around in a circle. Non-preemption, linking,
load-modules for functions, no system calls, no tasks, etc. I still don't
understand how you are going to prevent a programmer from bringing your system
to it's knees by: a) Not following standards, b) Forgetting a piece of logic,
c) Intent, etc. If there's nothing I like more about MVS (One of IBM's OS's),
is that it is virtually impossible to kill, no matter WHAT you do. That single
item is probably priority #1 by FAR in my design.
>> That's how TUNES see things: instead of building a huge number of
>> paranoid low-level checks, provide a high-level way (strong typing
>> and/or correctness proof) to ensure safety. It is infinitely more
>> reliable. As for self-foundation problem, of course there will have
>> to be some code we trust; but again this should eventually be as
>> small a portion of code as possible, and its sources shall be freely
>> available so anyone can check it and correct it. The least unreliable
>> thing is what everybody checked but nobody could make fail.
That's a great thing to hope to achieve. I forsee problems in the future,
though, about workload mix in this environment. Do you see it as an OS where
anyone can run anything, anytime that it's required? Background/foreground
jobs, online users, file servers, communications/network programs, programmer
development, management reporting, etc. etc. etc.?
>> And do have a look at the TUNES page (see URL below).
I'll have to do that. One reason is to find out what "annotated" means to
you guys. I'm having trouble relating that word to programs.
David Logan,
Boulder, CO
- -----BEGIN PGP SIGNATURE-----
Version: 2.6
iQB1AwUBL8qIJRylXvjtppttAQGSDAL9EnU9pn1L26AHPkri6omP0eTLpN74LK8a
5C+pXiWE088BNbvxmGkw0q2mtB1waf7xwOyXJELcWLJBMWwbd+qJBCVRWs+C+O1n
5sNmzRE2G4xQWd/gtV97w3veF2oqBMkZ
=3TBs
- -----END PGP SIGNATURE-----
<<>>
-----BEGIN PGP SIGNATURE-----
Version: 2.6
iQB1AwUBL8slhxylXvjtppttAQGqygL6A8dRcMNi6dXE+kUvXFh9O8Impf9YPCnt
j354V1aWAcDXMtVgNTl1SkoyrnFffVnRT4BXns9Zn9052lAQ9C5Al07s21gaH9L6
mL7U06FvB/jQDYgLPD3MgkFJc+IhxuXy
=q3j8
-----END PGP SIGNATURE-----