Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!rutgers!cbmvax!daveh From: daveh@cbmvax.commodore.com (Dave Haynie) Newsgroups: comp.sys.amiga.hardware Subject: Re: 50 MHz MC68040 capabilities? Message-ID: <9778@cbmvax.commodore.com> Date: 22 Feb 90 08:13:58 GMT References: <1129@mindlink.UUCP> <9691@cbmvax.commodore.com> <1013@metaphor.Metaphor.COM> Reply-To: daveh@cbmvax.cbm.commodore.com (Dave Haynie) Organization: Commodore, West Chester, PA Lines: 108 In article <1013@metaphor.Metaphor.COM> djh@dragon.metaphor.com (Dallas J. Hodgson) writes: >It seems to me that the state of Amiga speed-ups is at the primitive level that AT's >were when the first 12MHz boards came out. Just based on the nature of the machines, we're both ahead and behind what's happening in the PC market. All but one of the commercial accelerator cards are full 32 bit cards. The vast majority of the PC world isn't even running 32 bit code. Most folks are still using MS-DOS, which executes a really bad 16 bit model, the 8086 model. Some use the '286 model under various DOS add-ons or OS/2. When you're only fetching things in 16 bit chunks, addressing in 16 bit segments, much of the value of fast hardware is lost. Probably about 99% of what's done on a PC will run almost as fast on a 16MHz 386SX as a real 386, and much of it goes even faster on a 16MHz 286. The main value of a 33MHz 386 to most folks has merely been that you can't get a 33MHz 286 yet. UNIX, of course, is the one thing that really takes advantage of such systems. Real 32 bit code should go about twice as fast as 16 bit code. It's the extreme competition in the PC market that's driven this, without a doubt. Neither Amigas nor Macintoshes are settling into a basic high end of 33MHz and about 32-64k of external cache just yet. With Amigas that are currently shipping, the basic 32 bit systems are on coprocessor slot cards. Since you have a limited space here, you have your choice on card of supplying either 32 bit wide memory or a secondary cache. All of these cards have opted for 32 bit memory as a primary concern, and for good reason -- it gives you at least a four-fold speedup guaranteed. All the Amiga code in existance takes advantage of a full 32 bit bus. Far as I know, only the A2630 accelerator supports an add-on secondary cache, though no such card exists as yet. >For a long time there was big confusion over clock speed vs. wait states vs. >caching strategies, etc. People are still confused, and it gets worse when start thinking about the 68030, which has a much more efficient bus interface than either a '386 or an '020, but also supports lots more memory options. For example, the 68030 can fetch on longword every 2 clocks, which is every 80ns for a 25MHz part. Using burst mode with plain old nybble-mode DRAM (such as GVP's memory card), you can achieve the same thing, on paper -- 4 longwords in 8 clock cycles. If that's all there was to it, you'd have no need for any secondary cache; cache only makes sense when you're running with main memory wait states, at least until you get to multiprocessor systems. >I will put the question to all listening out there : Where are the boards with >Cache? As I mentioned, cache isn't yet the primary concern. But there's at least one system out there that will support it, should it become important enough for someone to work on. Truthfully, without a bit of research on the subject, there's some question how much a secondary cache will actually help things. Especially if it's the rather primitive direct mapped write through variety used on most of the PClones. >Where are the REAL specs? Who's currently shipping 68030 systems? I know of C-A, GVP, and whomever's currently selling the Ronin board. I've read all the details on the GVP memory system, we've discussed the details of that and the A2630 here on the net. >There's plenty of memory management variations on high-speed projects, (page-mode, >interleaving, write-back cache, write-thru cache) but I don't see this information >an any 3rd-party advertising. I'm no marketroid, but that doesn't surprise me. As an engineer, I wouldn't mind hearing of the details of these things. Benchmarks aren't a bad thing to publish, since most people can handle a number or two. But most of the people buying these things are not hardware engineers. Trying to explain the low-level differences and tradeoffs between burst fetching, memory interleave, SCRAMs, secondary caches, the effect of memory speed, etc. is simply going to confuse the vast majority of people out there. Not only that, anyone publishing gads of technical details in their ads are very likely trying to impress their customers with lots of powerful sounding technoid stuff that may not amount to a hill of beans. Every add ever written is desigend to make US sound good and THEM sound bad, wherever applicable. If you want technical details, benchmark results, etc. on Amiga systems, you don't count on ads, anymore than you should count on ads for PClones. You read reviews, lots of them. And comparisons. You _research_ before you buy, no matter what you're buying. If you don't, you'll only be lucky if you get what you really want. >And I don't want to hear that the 68030's on-chip cache is sufficient, it's not. Sufficient for what?!? The 68030 caches aren't large, but when they hit, the 68030 is going faster any any '386 every _dreamed_ of going. You are getting simultaneous fetch of instruction and data when both caches hit, each of which is faster than the '386 can fetch from any external primary cache. >We're paying big bucks for speedup boards now that could buy us 386's with >more efficient design. Anybody care to comment? While I agree that seconday cache would be a nice thing to have, and I'll most likely buy a cache board for my A2500/30 should anyone offer one, I think that statement is silly. You're overly concerned about technical details. Only a couple of things really matter: [1] Does it do what I want [2] Is it the best tradeoff of bang/buck vs. reliability out of the set of [1]. Market pressures and the Intel vs. Motorola architecture have pushed the Intel-based machines in one direction, the Motorola-based machines in another. >-Dallas "Down with Wait States" Hodgson -- 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