🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: net.micro.68k
Article #1031

Re: Re: BYTE "68000" issue

#1031
From: Dave Haynie
Date: Tue, 09 Sep 1986 19:32
83 lines
4963 bytes
> 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.
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Technical Details
Message-ID: <710@cbmvax.cbmvax.cbm.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!mnetor!seismo!lll-crg!lll-lcc!pyramid!amiga!cbmvax!daveh
References: <1327@lsuc.UUCP>

Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: arc1-ca.pugleaf.net!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