[unios] Re: Priorities

[Anders Petersson]

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

At 15:12 1998-12-03 -0500, you wrote:

[snip]
>Our goal is an OS for everyone.  I do believe we can have a flexible,
fast, secure
>system, that can fit the needs of everyone.  I don't think a flexible
system would
>be very much slower.  I think a system based on in-memory object oriented
hardware
>abstracts would provide for all the speed and flexibility we need.  The
way I look
>at it is:

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.

>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.

>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.

>> >> But we should take
>> >> the attitude of first constructing a technologically consistent
system, and
>> >> then see how it can be made fast (even if a good construction should be
>> >> pretty fast already). The opposite would be to first make a fast system,
>> >> and afterwards begin to look at how the system could be given the other
>> >> properties we want it to have. That's simply th wrong way to go, and
that
>> >> is why I did not put it on the primary goals list.
>> >
>> >Off course, but I think if you implement an architecturally good OS, it
>> >will be fast, stable and secure whatsoever.
>>
>> That depends. If you make the architecture with speed as your priority one,
>> you may define it as good. I would probably not think the same.
>
>I have to agree with what Pieter is saying, if we have a good design, it will
>inherently work fast and stable... I don't think special measures need to
be taken
>to make it so.

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?

>> I also think Beholder said a good thing... it *would* be harder to make the
>> OS less dependant on a specific hardware when designing for speed. If
>> machine specific optimizations is all that you require, then fine. But just
>> that doesn't give speed the right of the 2nd priority place. Optimizations
>> are really not as important as having a secure, flexible and well designed
>> system, are they?
>
>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?
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.

You skipped the exokernel, but seem to still think the same about the
holiness of speed.

BTW... have any of you got any advertisements in your mails? I haven't. :)

binEng

------------------------------------------------------------------------
To unsubscribe from this mailing list, or to change your subscription
to digest, go to the ONElist web site, at http://www.onelist.com and
select the User Center link from the menu bar on the left.
------------------------------------------------------------------------
UniOS Group
http://members.xoom.com/unios