Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!lll-lcc!pyramid!amiga!cbmvax!daveh From: daveh@cbmvax.cbm.UUCP (Dave Haynie) Newsgroups: net.micro.68k Subject: Re: Re: BYTE "68000" issue Message-ID: <710@cbmvax.cbmvax.cbm.UUCP> Date: Tue, 9-Sep-86 15:32:10 EDT Article-I.D.: cbmvax.710 Posted: Tue Sep 9 15:32:10 1986 Date-Received: Wed, 10-Sep-86 19:59:02 EDT References: <1327@lsuc.UUCP> Organization: Commodore Technology, West Chester, PA Lines: 83 > Summary: Are you sure? > >> >>* 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? Yes. Except for the TAS instruction, all 68000 bus cycles are the same, the 68000 requiring bus access during the last 2 of the 4 clock cycles, and the cycle either being read or write. The main advantage of the 68000's asynchronous capabilities is that any kind of slow memory can be read without any special hardware considerations. Put another way, you can run your 68000 as fast as the fastest memory in the system and still be able to access any slower memory with no penalty. Synchronous processors can do the same thing, but they usually have to be explicitly told to wait for the memory output (like in the Z-80 and the 6502). If, for some reason, you ran a system of several 68000s that were mutually asynchronous, you could call the asynchronous bus capabilities an advantage for multiprocessing, but most multiprocessing schemes would enforce at least some degree of mutual sychronization between processors. >>* 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. There's probably that confusion, since the magazine is concentrating, in this issue, on the 68000 specifically. The 68000 doesn't have built-in support for the 68881 dedicated math coprocessor as does the 68020, that's true, but it does support other 68000's in a multiprocessing environment via the aforementioned TAS instruction, which allows the 68000 to examine a bit flag without any possible intervention from an alternate processor, since it does read-modify-write in one cycle. Incidently, as far as I've heard, none of the top 3 popular 68000 systems support the TAS instruction. The AMIGA executes a read cycle for TAS; I believe that it will crash either the Atari ST or Apple MAC. >> >>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. >> >>-- > James Omura, Barrister & Solicitor, Toronto > ihnp4!utzoo!lsuc!jimomura > Byte Information eXchange: jimomura > (416) 652-3880 I didn't yet read this article either, but it does seem to me as well, overall, that BYTE is loosing some of its past excellence, especially in the areas of technical excellence. Its let numerous letter slip past that went beyond misleading to the realm of "completely wrong", and on various subjects that BYTE had the technical knowledge to correct or not publish in the first place. They aren't responsible for the material submitted to them, but they certainly are responsible for the content of anything they decide to publish. -- /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Dave Haynie {caip,ihnp4,allegra,seismo}!cbmvax!daveh "I gained nothing at all from Supreme Enlightenment, and for that very reason it is called Supreme Enlightenment." -Gotama Buddha These opinions are my own, though for a small fee they be yours too. \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/