daveh@cbmvax.commodore.com (Dave Haynie) (03/17/90)
In article <5812@tekig5.PEN.TEK.COM> wayneck@tekig5.PEN.TEK.COM (Wayne C Knapp) writes: >In article <100578@convex.convex.com>, swarren@convex.com (Steve Warren) writes: >> In article <6398@sbcs.sunysb.edu> root@sbcs.sunysb.edu (Systems Staff) writes: >> >In article <3951@nmtsun.nmt.edu> dksnsr@nmtsun.nmt.edu (Dr. Mosh) writes: >> [...] >> >>...based on pure processing performance, the 68040 IS Faster... >All of this talk about a 68040 being faster than anything isn't worth >anything until one can get a 68040 in a real system. However, there is one thing you can be certain about -- the 68040 will run your Amiga programs faster than any SPARC machine. And it'll certainly give any existing RISC machine a run for its money. For those who don't know much about the 68040, I can supply a few interesting details. It actually looks a bit like an 88k system, only on a single chip. Like the 88k, the 68040 has separate MMUs for the instruction and data paths, and large physical caches (4k each, vs. the 16k each of the 88k). However, cache hits happen as quickly as register accesses. This is extremely important for any older architecture trying to achieve the speed of the newer architectures. While the question of how many registers are needed is far from settled, most new architectures pick from 32 (MIPS and 88k) to zillions (SPARC and 29K). The 680x0 architecture guessed better than the 80x86, but it's still a bit short. But with cache access time the same as register access time, the need for more registers is greatly reduced, while at the same time maintaining compatibility. Another neat trick the 68040 uses is in its clocking. The 25MHz clock governs bus events, and in that sense a 25MHz 68040 exhibits external behavior similar to other 25MHz machines. But ALU and other internal events are governed by a 50MHz clock, allowing many internal things to happen much faster than they would in a traditional 25MHz CPU. Of course, just like the techniques used in RISC chips like the 88k were adopted and in some cases improved for the 68040, the next generation of RISC chips may be able to adopt some of the 68040's ideas, or others that have been explored since then. Another thing to consider, especially in the case of SPARC, is that no one's yet introduced a SPARC processor built with the same level of technology as the 68040. Sun's original version was built in a standard commercially available gate array, while the 68040's process is state-of-the-art 0.8 micron CMOS. So even if the 68040 now does "things" faster than some existing RISC CPUs, you'll eventually see RISCs out with on-chip floating point and cache that will very likely leapfrog the 68040. >So far it is just a bunch of talk. The 68040 is just being sampled now. Sure is... >There is no way the a company like Commodore is going to be able to get a >68040 based computer out this year. Remember, sports fans, who said it first. >When the 68040 is out in systems, it will make some sence to talk about >its speed compared to a sparc or 88K or whatever. However until there are >some real 68040 systems out it isn't really possible to compare performance. That's true. And until Motorola's shipping them in volume, rather than sampling, you probably won't be able to buy a 68040 system at all. Most 680x0 companies have known about the 68040, and how to build 68040 system, for quite awhile. So, like we saw last year with the 80486, as soon as production quantities are available, you'll see a number of systems become magically and instantly available (well, maybe YOU won't see them -- a good deal of 680x0 parts go into VME and other industrial computers, while 80x86s are mainly visible in PClones. You all know the PC/Workstation folks involved in 680x0 family systems: Amiga, Apple, Atari, Apollo/HP, NeXT, NCR, Sony...) > Wayne Knapp -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Too much of everything is just enough
oconnordm@CRD.GE.COM (Dennis M. O'Connor) (03/17/90)
daveh@cbmvax (Dave Haynie) writes:
] [...] But with cache access time the same as register access time,
] the need for more registers is greatly reduced, while at the same time
] maintaining compatibility.
This is all true of course. Comment : given a cache is as fast as
the registers, the registers still have a few advantage left over
memory locations : they are usually addressable in fewer bits, and
new results in them aren't written externally unless neccesary. (The
latter is sometimes an advantage :) And they don't need tag storage.
So, don't look for fast cache to make registers obsolete !
Memory-to-memory architecture ? Well, good effort, guys, good effort !
('round these parts, we use "good effort" to encourage people
on the other team when they make mistakes, hoping to train them
into making more :-)`
Follow-ups to comp.arch.
--
Dennis O'Connor OCONNORDM@CRD.GE.COM UUNET!CRD.GE.COM!OCONNOR
"Let's take a little off the top ... a bit off the sides ...
trim the back a bit ... Surprise ! You've been bald-ed !"eric@oakhill.UUCP (Eric Quintana) (03/17/90)
In article <10216@cbmvax.commodore.com> daveh@cbmvax (Dave Haynie) writes: >That's true. And until Motorola's shipping them in volume, rather than >sampling, you probably won't be able to buy a 68040 system at all. OK, OK. We're working as fast as we can! :-) I wonder how much faster we could get the 68040 out the door if I had a A3000 to work on. Perhaps we can make a deal. ;-) Seriously, I agree that it is tough to judge the speed of a part until you have it in a system. However, the performance numbers that Motorola tosses about are based on results obtained on a custom built system in our 'lab'. It has zero wait-state ram plus a myriad of hardware bells and whistles that no one but a chip designer cares about (eg. buserr capability on every cycle). Don't expect to see this system ever leave our lab, so your mileage may vary (but not by much, we hope). >Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" Eric Quintana ...!cs.utexas.edu!oakhill!eric