🚀 go-pugleaf

     I post this with some trepidation.  Again, I haven't read the article
in question, and am simply posting doubts about the criticism being voiced
so far.  At that, I have never written an OS myself and am new to the 68000
processor as a real owner, having just bought my Atari 1040ST and having
2 more computers in the planning stages, but delayed due to financial consi-
derations.  Anyway, let's see here:

In article <1058@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes:
>
>> UNIX and the MC68000 (by Andrew L. Rood, Robert C. Cline, Jon Brewster)
>> 	The powerful yet simple programmer's model offered by the 68000's
>> 	architecture makes UNIX implementation easy.
>
>Flame on.
>
>This article is the worst one I've seen in BYTE in a long time.  A shame,
>since it's probably the one closest to the interests of us on net.micro.68k.
>The authors work for HP in Corvallis, Oregon; maybe they are on the net.
>If so, guys, stand up and defend your article -- if you can.
>
>Here's a sample paragraph from page 198:
>
>"COPROCESSORS
>
>The MC68000 family allows for multiple CPU environments.  In the UNIX
>environment there is the possibility for much parallel processing if
>multiple processors are available.  The MC68000 bus operates
>asynchronously.  This aids in configuring buses with a multimaster
>capability that support multiple CPUs using the same memory and
>peripherals.  Many types of coprocessors are common to UNIX
>implementations, including floating-point coprocessors, graphics
>coprocessors, and DMA (direct memory access) processors.  Because UNIX
>is a multitasking system with multiple processes executing at any time,
>the operating system easily manages multiprocessor envionments."
>
>A few of the errors in just this paragraph:
>
>* Having an asynchronous bus has nothing to do with whether it supports
>multiple masters.

     John, are you sure about that?  I would think that an asynchronous
with a processor like the 68000 would be advantageous, first in any multiple
processor environment because the processor tends to need the bus at irregu-
lar intervals.  If processing was synchronous then a rotation scheme would
appear to me to be the best way to impliment multiple bus masters.  Because
it's difficult to predict when the bus will be needed on the widely varied
times in the rich 68K instruction set, a straight rotation looks very
inefficient to me and thus multiple bus masters would not be very practical.
The asynch bus looks to me to be a fairly advantageous thing to have.  Am I
wrong in this theory?

>
>* The authors are confused among coprocessors, multiprocessing, DMA,
>and multitasking.  A coprocessor as the word is typically used means a
>specialized chip which executes some instructions for the CPU, e.g. the
>float instructions.  Multiprocessing refers to having two or more
>identical or similar CPUs working in parallel, as on a Sequent machine

     Sorry.  I can't see anything here to criticise.  You say that the
word "coprocessor" has a "common" usage.  So what?  It *is* also used the
way the authors used it.  They weren't wrong.  For example, in one of my
68000 computers (half built) I have 2 Z-80 Co-processors one of which is
an alternative main processor and the other is a keyboard processor.  I
can write programs to *use* them as you are saying, but I need not even come
that close to conforming with your conception.  Actually, the keyboard
Z-80 comes conceptually closer to your description of multi-processing
since it runs off on it's own until it needs the bus and throws an interrupt.
The other Z-80, on the otherhand shares the RAM (not dual ported) with the
68000 and cannot run at the same time.

>or on large ibm "MP" machines.  DMA (Direct Memory Access) allows I/O
>devices to read or write memory without CPU intervention.  Multitasking
>means having more than one program appearing to run at once, as on all
>Unix machines.

     I don't see any evidence that they don't know any of the above.

>
>* Being able to do one of the above does not make the rest easy.

     That's a pretty broad statement.  I'm not convinced that the paragraph
you quoted necessarily meant each and every possibility you have denied.
Nor am I convinced you're necessarily right.  It would seem to me that a
multi-tasking environment would be a good way to utilize co-processing
and/or multi-processing.  In fact, any multi-processing is multi-tasking
in the broad usage of the word.

>
>* The 68000 does not provide direct support for any of these; they are
>implemented by software and/or external hardware.  (The 68020 directly
>supports coprocessors, but they are talking about the 68000.)

     Whaaa?  Hey, now the paragraph seemed to start off talking about the
68K family generally.  They may have mentioned the 68000 at one point there
specifically, but I think you're reading it a bit tighter than is called
for.

     Relax a bit, go have a beer and read the article in a more relaxed frame
of mind.  (Watch this.  I'll read the article and start screaming even
louder. :-)

>
>* Unix has a lot of trouble with multiprocessor environments.  People
>who run Unix on MP hardware did a lot of hard work on Unix to get
>there.

     (No argument.  Then again, I never thought Unix was wonderful anyway.)
>
>The above paragraph, while worse than most, is typical.  The authors
>demonstrate how little they know about Unix and system design
>throughout the article.  I thought BYTE was refereed and edited better
>than this, but it isn't.  With people like this "explaining" Unix to
>the masses, no wonder people don't understand it.  Flame off.
>
>-- 
>		     May the Source be with you!


-- 
James Omura, Barrister & Solicitor, Toronto
ihnp4!utzoo!lsuc!jimomura
Byte Information eXchange: jimomura
(416) 652-3880