Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!ulysses!allegra!princeton!udel!gatech!hao!noao!mcdsun!nud!rover!mph
From: mph@rover.UUCP
Newsgroups: comp.sys.amiga
Subject: Re: Still More 68020 Questions
Message-ID: <753@rover.UUCP>
Date: 15 Jan 88 17:31:13 GMT
References: <8801081459.AA16543@decwrl.dec.com> <3129@cbmvax.UUCP> <9055@ccicpg.UUCP>
Reply-To: mph@rover.UUCP (Mark Huth)
Organization: Motorola Microcomputer Division, Tempe, Az.
Lines: 25
Posted: Fri Jan 15 12:31:13 1988

In article <9055@ccicpg.UUCP> harald@ccicpg.UUCP ( Harald Milne) writes:
>In article <3129@cbmvax.UUCP>, daveh@cbmvax.UUCP (Dave Haynie) writes:
>> in article <8801081459.AA16543@decwrl.dec.com>, plouff@nac.dec.com (08-Jan-1988 0946) says:
>	Well to fill you in, the offending comments that appeared in the Feb
>issue of Amiga/World. 
>
>	To quote: (From page 28, first paragraph on that page)
>
>	"The 68020 naturally generates 32-bit addresses and expects data in
>32-bit chunks. It takes additional time for the processor to generate a 24-bit
>68000 address to access the 16-bit memory of the Amiga."
>
Now you know why I dropped my Amiga World subscription - too much
ignoramous verbosous.  The 68000 also uses 32 bit addresses - at least
from the code stream point of view.  It has full 32-bit internal
registers just like to '020 - in fact, the user model is identical.

The slower speed is most likely the result of a poor implementation of
the '020 to Amiga memory bus interface.  Say wasted cycles in
arbitration, or insertion of wait states to allow slow logic to
settle.  Another possibility is that somehow the '020 benchmark got
its stack misaligned of perhaps its data area - this would trap on the
68000, but runs fine, albeit slower, on the 68020.

Mark Huth