Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!caip!sri-spam!nike!ucbcad!ucbvax!hplabs!hp-pcd!andy From: andy@hp-pcd.UUCP (andy) Newsgroups: net.micro.68k Subject: Re: Re: BYTE "68000" issue Message-ID: <12700001@hpcvla.UUCP> Date: Fri, 12-Sep-86 16:16:00 EDT Article-I.D.: hpcvla.12700001 Posted: Fri Sep 12 16:16:00 1986 Date-Received: Tue, 16-Sep-86 21:41:04 EDT References: <1058@hoptoad.UUCP> Organization: Hewlett-Packard - Corvallis, OR Lines: 172 Nf-ID: #R:hoptoad:-105800:hpcvla:12700001:000:8350 Nf-From: hpcvla!andy Sep 12 12:16:00 1986 >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