release 0.0.0.20 and thoughts

[Billy Tanksley]

On Sun, 13 Aug 1995 spc@gate.net wrote:

> >    It's worse than that: it's not even decidable !
> > But why should that prevent us from supporting it ?
> > That a program may run at all is undecidable. Will you design
> > computers so that they won't support programs that run ????????
> >    Will you prevent compilers from removing *any* run-time check just because
> > the general problem of deciding whether this is possible is undecidable ???

>   Well, there are certain cases where it's easy to check, but there comes a
> point where it's just plain silly to decide certain attributes about a
> program.  Hypothetical case:  The Ackerman Function.  Given the following
> (it's in C but it could easily be done in any language):

>   I know, I know.  You can run it in the "Isolation Box (TM)", but this is
> the type of thing I'm talking about.

Actually, from what I've heard from here, you have two choices in modern 
OS design: OSes that are secure because they're paranoid (isolation 
boxes) and OSes that are insecure because they don't isolate.

Fare' and co. appear to me to be wanting to add a third category to that: 
OSes that are secure because they can choose intellegently whether or not 
to isolate.

So, the solution to your problem is: if you, the programmer, can prove 
that formula, and state that proof to the computer, TUNES will not 
isolate it.  If you can't, it will, and you'll be running at the same 
speed as any other 'modern' OS.

However, there are certain things we CAN prove about that function.  We 
can't prove that it terminates, but we can show that it doesn't modify 
any permanent variables.  We can also show that it does or doesn't yield 
control to the multitasker.  We can show that it doesn't trash memory 
(aside from the recursion stack, which is contained anyways).

In other words, it may never finish, but it will run safely.

>   Can you present a high-level proof that the Ackerman Function works?  The
> definition is there in the code.

Depends what you mean by 'works'.

> >    Apart for microkernels (that completely suck), I completely agree.

>   Well, can you explain WHY a microkernel sucks?  

He seems to think they're slow.  I'm just listening, but I haven't heard 
why yet.

> > >   And it's that thinking, where memory is infinite, that lead to the current
> > > state of systems, like Windows or modern Unix systems.  You may find it hard
> > > to believe, but I have, sitting next to me right now, a Unix based box with
> > > only 512K physical RAM (probably a few meg total in virtual memory) with a
> > > 15M harddrive.  With a kernel size of 69.4K.

> >    You don't seem to get my point. I have never ever said that memory was
> > plenty and could be wasted, or that each node could be assumed to have as
> > much as possible.

> >    What I've been saying is that there is a qualitative leap in the amount
> > of available memory. Fifty years ago, memory was just enough for tiny
> > programs to exist. Meta-operations were hand-done by humans. Then, the
> > computer could automate recording and restoring so humans needed retype
> > programs. Then it could handle simple compilation so humans needn't
> > hand-assemble programs. 

>   Okay, that takes us to about 1955.  The point I was making is that it
> SHOULDN'T take megs and megs of RAM to do what is currently being done. 
> Yes, OO is neat.  But does it REALLY require 4M of RAM?

OO SHOULD make all (eqivalent) software smaller.  Most implementations 
now, therefore, are not OO.  QED.  :)

There are some well-implemented OO systems out; the only one I actually 
have used to any extent is PC-Geos, since it comes with a VERY powerful 
word processor.  It's a multitasking, multithreading, OO, GUI OS that 
fits in 4M of ROM and runs in 512K.  That 4M ROM includes things like 
scalable fonts, context-sensive help, and miscellaneous stuff.

Best of all (and most promising for TUNES), real applications (like that 
word processor) can use the OO system to great advantage-- the entire 
executable for that full-featured WP is 83K big, including all the graphics 
and such.

>   And I'm not saying that we should go back to the days of 64K, or even 16K,
> 4K or even 1K.  What I'm saying is that there's a bloat to todays code that
> is incredible, and the smaller it is, the more memory left over to
> manipulate data, and THAT'S what the computer is there for, to manipulate
> data.

I agree.

>   Now, sending a message or attempting to gain a semaphore are forms of
> yield(), in that the calling execution unit is blocked until the condition
> is met (and in my Amiga example, that's why 16 tasks can be in the system
> without taking CPU time at all, because they're all blocked).  

Just a sec.  Sending a message outside of your thread should not block 
you; it probably should do a yield, but no blocking.  Now calling a 
method is different.

> Preemtive multitasking doesn't prevent two execution units from cooperating. 
> No, really, it doesn't.  

As I understand it, the reverse is also true.  Coop multi does not 
prevent an object from preempting its own decendants.

>   Please, don't take away my freedom to do stupid things to my computer.  I
> thought that's what TUNES was about.  And if I want preemtive multitasking,
> I should be able to add it, no?  But here you are, dictating what YOU thing
> everybody should want.

No, he's dictating the basic design of TUNES, and he's trying to keep it 
open.  The nice thing about cooperative multitasking is that you can 
easily replace it with preemptive-- you can't go the other way around.

>   -spc (Will play Devil's Advocate for food)

-Billy