Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!nosc!ucsd!rutgers!uwvax!umn-d-ub!umn-cs!mmm!ems!srcsip!shankar From: shankar@srcsip.UUCP (Subash Shankar) Newsgroups: comp.sys.apple Subject: Re: Thoughts about the rumored gs+ Message-ID: <6554@altaira.srcsip.UUCP> Date: 26 Jul 88 01:03:36 GMT References: <8807182116.aa05050@SPARK.BRL.ARPA> <1260002@hpclkms.HP.COM> Reply-To: shankar@wabasha.UUCP (Subash Shankar) Organization: Honeywell Systems & Research Center, Camden, MN Lines: 30 In article <1260002@hpclkms.HP.COM> ken@hpclkms.HP.COM (Kenneth Sumrall) writes: >/ 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) >> >>... >... >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. Exactly. On the pro side for the 68000, there is the larger datapath width (double), the existence of (reasonably) high speed advanced arithmetic (multiplication particularly), and the existence of a large number of registers. On the pro side for the 65816, there is the dramatically fewer cycles per instruction, and the existence of a relocatable zero page which effectively give you up to .5*(64K - stack_size) 16-bit registers with zero context-switch overhead. In short, there is no means for comparison. I personally feel that a 8 MHz 65816 would run circles around a 8M 68000 for general purpose applications, but would be just as dramatically pitiful when doing any arithmetic. Graphics would probably be slightly faster for general drawing and slightly slower for plain image moves.