Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!think.com!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: 14 Jun 91 22:11:38 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: 61 In-Reply-To: daveh@cbmvax.commodore.com's message of 13 Jun 91 05:53:47 GMT Nntp-Posting-Host: largo.mitre.org In article <22393@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: Anyway, looking at the Motorola track record, the '050 should be in the "evolutionary" category, which is tracked more on architectural grounds than performance upgrades: 68000,68010 16 bit 68020,68030 32 bit 68040,68050 Cool 32 bit 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 The 68050 is of course my WAG, but the easiest way to pump more performance out of the architecture without increasing the clock would be to add more data lines. (I'm sure the cache sizes will also increase, but the remaining advantage from that is in the noise.) Increasing the instruction and data path separation might help some, but if you are going to have more lines off the chip, might as well make them multipurpose by widening the the path instead of having two parallel paths. I think anyone who wants to significantly better the MIPS/clock of the current generation is going to have to go to wider busses like the RS/6000 and the HP Snake. I don't think that there will be any need for additional address lines in the 68050, but with the current generation having MMU's on board, allowing more physical memory than per user virtual memory is very cheap. There are machines out there NOW pushing the 4 Gig 32-bit addressing limit. It's just hasn't happened in the workstation market yet. Most of our workstations here are around 16 Meg, but we do have one Sun with 128 Meg, so the four Meg limit could become a problem in the 68050 time frame. (Although--if you know what you are doing--the current 680x0 scheme has 16 4 Meg address spaces, and a clever hardware design could support several user segments. But much better to do it right in the next chip and not get into Intel style kludges.) > Except for the 68000 to 68010 upgrade, each step so far has been at > least a factor of two improvement. Depends on what you are building and how you count! Because of the uninterruptable instruction problems in the 68000 (some instructions in the 68000 cannot be correctly restarted after a page fault), at Stratus it took twice as many 68000's as 68010's to make a logical CPU. (Eight 68000's or four 68010's if you care.) So for most people doing demand paged virtual memory, the 68010 was more than a factor of two improvement. :-) -- Robert I. Eachus with STANDARD_DISCLAIMER; use STANDARD_DISCLAIMER; function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...