[unios] Re: Priorities

[Anders Petersson]

From: Anders Petersson <anders.petersson@mbox320.swipnet.se>

At 21:06 1998-12-03 -0500, you wrote:
>From: Pat Wendorf <beholder@ican.net>
>
>> If I understand, you have come up with the amazingly good idea of including
>> all *good* features, and excluding all *bad* features. Gosh, why haven't
>> anybody thought of that before?
>> OK, I don't want to sound too critizising; except for the target market, we
>> agree on most things.
>
>I don't know how you find it so hard to believe that there is a common ground
>between all users...  Explain here why you think it's totally impossible.  A
>computer is a computer.  It can be same computer that runs an assembly
line, a
>game, a word processor... Why is it we should have 3 different OS's?

I do not think that an OS for everyone is impossible. But I, as the only
person here as it seems, have in mind that there *are* trade-offs.
Two relevant trades-offs are: security vs. speed and generic solutions vs.
speed.
An OS that fulfills everybody's needs might in theory not be a good OS for
*anyone*, since it has to, as every OS has to, make trade-offs.

The examples you mention can well be fitted into the same OS, and I think
UniOS should do it all. In principle I'm not against the OS for everyone...
but if giving speed as high priority as Pieter wants, you are making it
extremely hard for yourself.
I could agree on 'an OS for almost everyone', if you make the speed issue
less dominant.

>> >1) A program, which is a collection of  in-memory objects is run, and when
>> it has
>> >to access hardware (I/O),  it can simply call routines in the hardware
>> abstracts,
>> >which are already sitting in memory... so I see one decision statement,
>> and a call
>> >instruction.  Both of these instructions on a Pentium processor only take
>> about 2
>> >cycles each (I may be wrong about the call, I think it takes 4)...  But
>> the idea
>> >is: it may not be in-line code, but it is still not very far off.   The
only
>> >assumption we have to make here is that the hardware abstracts are not
>> huge, and
>> >take up tons of  memory.  In this I don't see any noticeable slowdown.
>>
>> Essentially I agree. But is this really so much different from usual device
>> drivers? Yes, this method is more general, but it certainly won't bring
>> heaven down.
>
>Nor the speed of the programs or OS... that was the point :)

I thought this was what you all referred to as the speed solution... ?
Actually, I'm not very fond of the term 'hardware abstraction'. Why not
simply call it 'drivers'? We still know what we mean... and it's shorter to
type.

>> >2)  To make a system that is flexible in any way, we have to reduce the
>> desire to
>> >have "perfect" code.  An industrial process machine, would ideally need
>> "perfect"
>> >code, but this can be very closely simulated simply by allowing the system
>> to shut
>> >down some of it's background processes (like the multi-tasker).  This
way the
>> >industrial process would run with the same features of the OS, but without
>> ever
>> >having control taken away from itself (just make damn sure the programmer
>> put in a
>> >way to exit the program :).  So long as you can make a process
repeatable and
>> >stable, you can make the industrial world happy.
>>
>> What do you mean by "perfect code"?
>> I agree on the stuff that I understand. :) This kind of flexibility is
>> good, and should be supported.
>
>Perfect code, is code that has been written from the ground up to support the
>exact devices that the system has.... Kinda like Video game console
systems (Sony
>Playstations, N64, ect)... Programmers write code exactly for that system.
 It can
>produce the fastest, smallest, most stable code possible, hence the term
"Perfect
>code".  With PC's, or specialized servers, or even MAC computers, you can
change
>your hardware, and therefore never be able to produce perfect code that takes
>advantage of every piece of hardware, at least, not a mass scale.

Again we have prooved the difficulties of the language barrier. This is
about what I said further down. And we agree.

>> Wait, wait. You missunderstood me, I think. I too believe that good methods
>> bring speed. But what is a good OS is dependent on the who watches. If your
>> only consideration is speed, UniOS won't be the perfect system *for you*.
>> Don't you agree?
>
>Yes, if you design the OS for a specific architecture (a kind of
optimization), it
>will not port well, and probably be more difficult to program.

What you think is a good system depends on what characteristics you are
looking for. That is what I was trying to say, and I guess it's most of all
a fact, not some personal opinion.

>> >Yep I agree... I just think we're on the wrong track by saying that
speed and
>> >flexibility are contrary concepts.  I think speed and flexibility are just
>> >contrary to memory requirements.  We may need more memory to achieve what
>> we want,
>> >then if we optimized programs exactly for the hardware.  Although I don't
>> rule out
>> >this system yet, I just don't have any ideas on making it flexible.
>>
>> What system don't you rule out, you said?
>
>The system that compiles the device access routines within the
executable... we
>discussed this ourselves, and came to the conclusion that it would be
difficult...
>not impossible, but difficult.  Until it's totally impossible, I will not
rule it
>out.

I rule it out. It would be bulky and unflexible. The only reason would be
speed... and for the big majority of users the disadvantages are far bigger
than the advantage. For the few systems with such *extreme* speed
requirements, something like that could be done, but not for every system.
Let's lay this idea aside for now.

>> No, speed and flexibility is not contrary, but I think the system can't run
>> at the maximum theoretical speed... partly because of the flexibility,
>> which in general means we cannot hardcode features, but have to refer to
>> system level objects all the time.
>
>Yes, I see what you mean now. That I can agree with.... it's can't be
perfect.

Yes, the same thing as you said before.

>> You skipped the exokernel, but seem to still think the same about the
>> holiness of speed.
>
>All I want is to avoid being another Java...  Speed has to be thought about.

Of course speed has to be thought of. When the system comes to the final
user. However (you knew I'd say that, not? :) ), if speed is to be the
second most prioritied feature, you are not looking for a generic system,
but some critical industrial system.
By giving speed higher priority than generic solutions, you are effectively
defeating your own goal; an OS for everyone. We need generic solutions. The
opposite is solutions for specific situations and environments. Maybe the
importance of generic solutions becomes more self-evident now?

For critical uses, a flexible system can be customized to improve speed,
like by disabling the multitasker and shutting down daemons and such...

I'm quoting Daisuke from his mail, to tie the discussion together:
>Optimization from the start is the most important feature and all thru
development, 
>if not then it might be impossible to do so later on and it'd have to be a
start-from-scratch all over 
>again.
>performance is also a biggie if you comtemplate that UniOS should be
compatible with every platform 
>out there

The design should be made with speed in mind. That is, we have to make sure
the design allows for a resonable speed when optimized. It is not resonable
to begin to optimize on a full-scale before the core system is otherwise
done. Beholder mentioned that maybe the first version should be programmed
in Java. This somewhat shows my point - first make sure the thing work,
then de the optimizations you planned for at the beginning.
Daisuke is on the wrong track when he says that optimization from the start
is THE MOST important feature. I wouldn't even put that on the priority
list at all.
Would optimizations later on be impossible? Not if the system is not
completely wrong. What really *could* proove impossible to do later would
be to make the system generic. This is something that *have to* be
considered when constructing the model.
You can give a car a faster engine or tires afterwards, but you can't give
it a better design without reconstructing it.

Performace a big issue because of compability? I can't see why.

And... it would be nice it someone agreed with me... please? ;-)

binEng

------------------------------------------------------------------------
Help support ONElist, while generating interest in your product or
service. ONElist has a variety of advertising packages. Visit
http://www.onelist.com/advert.html for more information.
------------------------------------------------------------------------
UniOS Group
http://members.xoom.com/unios