Arch support for C

[Bob Larson]

In article <399 at ccird1.UUCP> rb at ccird1.UUCP (Rex Ballard) writes:
>As to the superiority of UNIX over other operating systems, there are
>few who think UNIX couldn't be improved.  The big question is how?
>I'm sure we will be seeing a rapid evolution of UNIX and UNIX-like
>operating systems as multi-tasking micros and multi-processing minis
>become mandatory state of the art, rather than expensive luxuries.
>Hopefully, a few of them won't be "designed by commitee",  Unix
>started out right (a small group trying good ideas), but evolved
>into a slow memory pig.
Which leads to the UNIX definition in the os9/68k users manual:
"An operating system similar to os-9, but with less functionality
and special features designed to soak up excess memory, disk space
and CPU time on large, expensive computers."

>It would be nice to see Unix modularized, so that the whole kernal
>doesn't have to be re-linked just to add two lines of code to a
>driver.  
As in os9.

>It would be nice if the queuing and signalling as well as
>the context switches could be cleaned up.  

>It would be nice to have
>generic "transaction" mechanisms similar to pipes, so that work could
>be shared between processes.  
Are os9/68k's named pipes what you are looking for?

>It would be nice to have locks, so that
>processes that wish to recieve input from several processors could do
>so in real time.  

>It would be nice if "system libraries" were "sharable"
>so that less copies of "printf" were taking up swap space.  
As in os9/68k, but I prefer how it is done in primos 19.4 and beond.  
(Primos uses some hardware support: fault bit on pointers.)

>It would
>be nice if all but the bare bones drivers could be "tasks" rather than
>part of the kernal, so that only that which was needed at the moment
>would sit in core.  
I think os9/68k has what you are asking for here.

>The list goes on, but most has been hashed to death already.
And much of it is unique to unix.  Not all "Unix-like" operating systems
are bug-for-bug compatable.

>If we wish to come up with better products, we have to look at both the
>best and the worst in the best and worst of systems and languages,
>operating systems, and archetictures.  I haven't seen a system yet
>that is so good that it can't be improved, or a system so bad that
>there wasn't at least one or two good features in it.
I agree.



-- 
Bob Larson
Arpa: Blarson at Usc-Ecl.Arpa
Uucp: ihnp4!sdcrdcf!usc-oberon!blarson