Path: utzoo!utgpu!water!watmath!clyde!att!pacbell!lll-tis!helios.ee.lbl.gov!nosc!ucsd!ucsdhub!hp-sdd!hplabs!hpl-opus!hpccc!hp-sde!hpda!hpcuhb!hpcllla!hpclisp!hpclkms!ken
From: ken@hpclkms.HP.COM (Kenneth Sumrall)
Newsgroups: comp.sys.apple
Subject: Re: Thoughts about the rumored gs+
Message-ID: <1260002@hpclkms.HP.COM>
Date: 21 Jul 88 17:04:14 GMT
References: <8807182116.aa05050@SPARK.BRL.ARPA>
Organization: HP NSG/ISD Computer Language Lab
Lines: 28

/ hpclkms:comp.sys.apple / oliver@thelink.UUCP (Joel Sumner) /  2:51 pm  Jul 20, 1988 /
>>In article <8807182116.aa05050@SPARK.BRL.ARPA> Asaf Sokolowski writes:
>>                                      SE  *            //gs+
>>speed in MHz (standard)               7.x              7.x
>
>Excuse me but isn't comparison of Mhz speeds between a 32-bit 68000 and a 
>16-bit 65SC816 kinda like comparing Apples to Oranges (no pun intended)
>
>I would think that 8 extra bits to work with would have some sort of increase
>in speed not to mention the 816's  8 bit data path limit to the rest of the
>machine...

Sorry about the previous posting with no new information.  I am used to using
rn and am now being forced to use notes against my will, and I haven't learned
it yet.

The real problem with comparing these clock speeds is that on the 68000, each
bus access cycle takes FOUR CPU clock cycles, whereas on the 65816 and ilk,
each bus access cycle takes ONE CPU cycle.  This makes quite a difference when
running programs that manipulate large amounts of data, and I think that a
8 Mhz 65816 would outperform an 8 Mhz 68000 in many applications.  Of course,
you pay a penalty in RAM prices since an 8 Mhz 65816 would require 70ns RAM.

BTW, please don't flame me for voicing my humble opinion, since my flame
retardent suit is at the cleaners. 

Kenneth Sumrall
INTERNET: ken%hpclkms@hplabs.hp.com