🚀 go-pugleaf

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

  Yes, HP Corvallis is on the net and listening.  Sorry you were so 
  disappointed about the article.  Perhaps BYTE is not a good magazine 
  for you to continue to read.

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

  While it is true that all forms of machine exist (i.e. asynchronous bus
  with/without multiple masters; synchronous bus with/without multiple
  masters); I do not agree that the form of bus synchronization and the
  implementation of multiple masters are unrelated.  As per the opening 
  comments of the article the concern is with actual implementation, not
  theory.  My belief is that multiple bus masters are easier to implement and
  configure in an asynchronous bus environment.

  This point is debatable.  However, in defense of our article keep in
  mind that whatever viewpoint is championed, it must be so championed
  in at most two paragraphs.  The BYTE editors specifically requested that we
  condense a more complete discussion of coprocessors into the two
  paragraphs of this section.

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

  First, the authors are not confused (they may be incorrect, but not
  confused).  In this section I am using some of the terminology of
  the OSU EE-CE department graduate architecture sequence which I taught
  last quarter.  Having difficulty compressing a full quarter's material
  into one paragraph, I opted to use only the term coprocessor (note that
  multiprocessing, multiprocessors, slave processor, I/O processor,
  tightly/loosely coupled processors, array processor etc etc; are not
  used at all in the article). 

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

  Yes, being able to do one does not necessarily imply that others are
  easy.  However in real world design those design characteristics
  which support one are often useful in support of others.

  Again, Your point may be true in the abstract theory of it, but
  in reality these different types of multiple processor designs involve
  some similar design problems.  Remember that the thrust of this
  article is not coprocessors, and it is not UNIX, the thrust is 68000
  family architecture.  We were informed when writing the
  paper that there would be another article on multiple processor
  configurations in the same issue, therefore we were asked not
  to go into the topic more than briefly.

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

  See previous note regarding this.  This article is talking about the
  68000 family, including the 68020.  Please read more carefully.

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

  I would agree that UNIX has a lot of trouble with some multiprocessor
  environments.  However, my contention is that because UNIX presumes
  a multiple process model of computation, it is easier to make use of
  multiple processors than it is in a single tasking (or single process)
  environment.

  The HP series 500 for example is a multiprocessor environment (using 
  your terminology where multiprocessor implies several identical processors)
  which runs UNIX and effectively uses processors on a per process basis.  
  The HP series 200 machines use 68020s with 68881s (presumably a correct 
  use of the term 'coprocessor' in your usage) and implement UNIX
  using both processors without taking advantage of the multiple
  process nature of UNIX.  The 68881 processor does not make UNIX
  implementation difficult however.  Perhaps you are speaking of
  classical array processors or other tightly coupled multi-processor
  systems which have difficulty implementing UNIX so as to gain from
  the presence of multiple processors.

>
>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.
>
>-- 
>John Gilmore  {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu   jgilmore@lll-crg.arpa
>		     May the Source be with you!
>/* ---------- */

  Flame on-

  Why be so disparaging of the article yet provide no substance to
  your disparaging remarks.  If you found the prose or grammar of the
  article to be sub standard then please let me know via net mail.
  If you have some real substanitive complaints then what are they?

  I am not familiar with BYTE's general policies, however this article
  was not refereed, it was solicited.  The article outline and contents
  were agreed to with the input of BYTE technical editors.   We wrote
  the article after being requested to do so by BYTE.

  This article is NOT explaining UNIX!  Please read more carefully.
  The BYTE staff specifically requested that we NOT attempt to explain UNIX.
  Please keep in mind that the general BYTE audience is very large and
  NOT as technically expert as the readership of this notes group.
   
  I believe the article is well written and accomplishes precisely
  what it attempts.  You seem to be dissatisfied because the article is
  not a highly technical, completely comprehensive UNIX summary.  The
  article was never intended to be.  The majority of BYTE readership
  (as represented to us by the BYTE technical editors) is interested in
  precisely the type of article we generated.  The intent was not to be
  highly UNIX technical, but rather to focus on the 68k family.  The intent
  was to address a less sophisticated group of readers and provide an
  initial view of some UNIXisms and how they relate to the 68k.

  I do NOT see merit in your complaints with my coprocessor paragraph.
  You have isolated two areas which are moot, however you have
  jumped to your own conclusions about what the paragraph implies and
  then contradicted your own conclusions.  

  If you have some items of substance in which the article is incorrect, then
  let's hear them.  Not items where your conclusions are incorrect, items
  which are part of the article.

  Your comments regarding competance as UNIX implementors and system
  design are not supported.  We do UNIX implementation and 68k family
  system design here in Corvallis.  HP has great competance in both fields.
  We produce real, innovative products which work and sell.  That is sufficient
  proof of our competance for me.

  Go get a beer and mellow-out, John.

   -Flame off

  Andy Rood    ... {hplabs,hpfcla}!hp-pcd!andy