Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site lsuc.UUCP Path: utzoo!lsuc!jimomura From: jimomura@lsuc.UUCP (Jim Omura) Newsgroups: net.micro.68k Subject: Re: BYTE "68000" issue Message-ID: <1327@lsuc.UUCP> Date: Fri, 5-Sep-86 00:07:21 EDT Article-I.D.: lsuc.1327 Posted: Fri Sep 5 00:07:21 1986 Date-Received: Fri, 5-Sep-86 00:55:01 EDT References: <3868@ut-ngp.UUCP> <1058@hoptoad.uucp> Reply-To: jimomura@lsuc.UUCP (Jim Omura) Organization: Barrister & Solicitor, Toronto Lines: 124 Summary: Are you sure? 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