Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!agate!ig!uwmcsd1!tut.cis.ohio-state.edu!ut-sally!utah-cs!utah-gr!uplherc!sp7040!obie!wsccs!terry
From: terry@wsccs.UUCP (terry)
Newsgroups: comp.misc
Subject: Re: Message based OSs (was "Re: GNU Manifesto")
Message-ID: <185@wsccs.UUCP>
Date: 25 Feb 88 08:31:20 GMT
References: <1447@sugar.UUCP> <227@gandalf.littlei.UUCP>
Lines: 86
Summary: Message based architectures

In article <227@gandalf.littlei.UUCP>, adams@littlei.UUCP (Robert Adams) writes:
> From article <1447@sugar.UUCP>, by peter@sugar.UUCP (Peter da Silva):
> 
> I would like an explanation of this.  It seems like it [message based os's]
> would be a
> wonderful computer architecture discussion because many systems are
> moving from procedural based interfaces to message based interfaces
> and, if that tends to create code that's inherently buggy, we certainly
> have a problem on our hands.

	I have a comment on this;  the one gripe I have with my Amiga is it's
message based OS... or rather, the library routine interface to it.  I don't
think that message based architectures are an inherently bad design, but if
you do not support the defacto standard library calls for portable code due
to difficulty of implimentation, you're going to have problems.

	In general, when one is porting low-level stuff to an Amiga, it seems
to be a one-way process.  In addition, the only operating system I have found
myself able to port _from_ with ease is VMS... another message-styled system.

	I think that in general, the problems with a message based OS are
threefold:

	1) Portability of existing code is severly restricted.
	2) Size of code increases dramatically.
	3) There is significant system degradation when such a system is
	   _forced_ to provide decent response time to a real-time request.

	Point 1 above may be ripe to be thrown out (I personally disagree
with this; I *like* portable code) due to the general inability of a prior
technology to predict future trends with accuracy.  Simply put, it is just
possible that current code may reflect architecture-dependent structures
which are inherently not portable to newer (presumedly better?) architectures
without a great deal of effort.  This points to acknowledged inadequacies in
current architecture (else why develope a newer, penalizing one?).  I, for one,
refuse to port 'normal use' software to the 64,000 processor GoodYear box.  In
addition, I have gigs of stuff I would prefer to have around, but can not
afford to spend time to port.

	Point 2 will probably be resolved _if_ new chip architectures take
steps to impliment primary functions of message passing in hardware, therby
reducing or eliminating additional code overhead normally incurred in an
implimentation of a message passing on current chips (say the 680x0).

	Point 3 will probably be resolved the same as point 2, but I have
grave reservations.  It is well known that current modifications, such as
the multi-processor support, in the 'new generation' VAX machines from DEC
has been specifically implimented to not 'clash' with their VMS operating
system.  This would lead one to believe that current VAX architecture is a
refection of DEC's 'making VMS run better' via hardware support for the OS.
From personal experience, I can tell you that a MicroVAX II running VMS is
unable to maintain a serial baud rate (no flow control) at speeds greater
than 2400 baud using Digital's SET HOST/DTE command (a supposedly 'optimized'
portion of VMS) out a standard DHV11 controller when ANY processor loading
occurs.  There are a number of work arounds, of course, but they all involve
'unoptimizing' something... device drivers, I/O calls, etc.  Serial I/O in
a multitasking environment suffers as well on the Amiga.  I have found the
message passing multi-tasking kernal to be unable to support a throughput
of greater than 2400 baud when the POSSIBILTY of other tasks exists.  Again,
non-optimization will speed this up.  Absolute optimization through either
obscene priority boosts or non-highlevel (read: non-portable) modification
of low-level drivers, again, returns the system to adequate performance, but
at a sacrafice of other capabilities.  If one grabs the whole machine (or runs
at a high priority and is written in assembly), one can go well in excess of
38400 baud.

If my examples seem limited, note that they are _examples_, not speculation,
and are taken from personal experience.

I think that unless there is a great deal of hardware support, we are not
going to see a great deal of message-based OS's in wide use for any type of
real-time or machine-portable operations.  A message-based OS semms to imply
(to me, at least) the ability to communicate, in real time.  This implication
is supported by the 'transputer' hardware architecture which allows message
passing not only within a processor, but to other processors.  Unless the
country suddenly goes hi-speed digital, I do not forsee a bright future in
anything but transaction processing or some other get-it-done-in-a-finite-
but-possibly-longer-than-optimum-period-of-time application.


| Terry Lambert           UUCP: ...!decvax!utah-cs!century!terry              |
| @ Century Software       or : ...utah-cs!uplherc!sp7040!obie!wsccs!terry    |
| SLC, Utah                                                                   |
|                   These opinions are not my companies, but if you find them |
|                   useful, send a $20.00 donation to Brisbane Australia...   |
| 'There are monkey boys in the facility.  Do not be alarmed; you are secure' |