Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!linus!linus!linus!mbunix!eachus From: eachus@largo.mitre.org (Robert I. Eachus) Newsgroups: comp.sys.amiga.advocacy Subject: Re: The 68050 - end of the 680x0? (was Re: The Amiga's Future) Message-ID: Date: 19 Jun 91 22:21:37 GMT References: <5068@orbit.cts.com> <16647@darkstar.ucsc.edu> < <1308@cbmger.UUCP> <28@ryptyde.UUCP> > <01dH!cmr@cs.psu.edu> <1991Jun10.072945.8821@neon.Stanford.EDU> <22365@cbmvax.commodore.com> <1991Jun13.003707.19785@neon.Stanford.EDU> < Sender: news@linus.mitre.org (News Service) Organization: The Mitre Corp., Bedford, MA. Lines: 48 In-Reply-To: daveh@cbmvax.commodore.com's message of 17 Jun 91 21:11:55 GMT Nntp-Posting-Host: largo.mitre.org In article <22515@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: In article eachus@largo.mitre.org (Robert I. Eachus) writes: > I don't know what Cool 32 bit is, but I see the splits slightly >differently. > 68000, 68010: 24(27)-bit address, 16-bit data > 68020: 32(36)-bit address, 32-bit data > 68030, 68040: 32(36)-bit address, 32-bit data with cache fill support > 68050: ???-bit address, 64(128-bit) data If you see things that way, you're ignoring the underlying architecture, for other than the 68050 (which we don't know about).... Motorola did a hell of a lot of things right in the 68040, and you are correct in pointing out that under the skin, the 68040 looks more like an 88000 that a 68020. My grouping of the 68030 and 68040 in that list was NOT intended to imply that the innards were at all related, just that memory designs that support the 68030 do a reasonably good job of supporting the 68040, while both you and I (come on, admit it Dave :-) switched bus designs completely between the 68020 and the 68030. Getting maximum performance out of the 68020 meant an external cache, while low end machines used the on-board cache. The number of clocks needed to feed data to a 68020 meant that any simple 32-bit data bus could make it happy. While it is possible to treat a 68030 like an overgrown 68020, and Apple did so in some of their machines, with the 68030 you had to improve the memory system (and the bus) to keep up with the chip which could now eat data (or instructions) at more than twice the previous rate. The 68040 can draw from main memory a little faster than the 68030, but the cache is much more effective, so a bus designed for a 68030 at the same clock speed can feed a 68040 (modulo that one clock cycle), just like the same bus bandwidth would feed a 68000 and 68010. My guess is that the 68030 and 68040 are eating all the data a 32-bit wide bus can handle so the 68050 will have to go wider, and it will be time to redesign systems again, not just CPU boards. (Of course, in the meantime some people will pay good money for 40 and 50 MHz 68040 systems, and feeding those will be a real challenge!) -- Robert I. Eachus with STANDARD_DISCLAIMER; use STANDARD_DISCLAIMER; function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...