Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!texsun!convex!swarren From: swarren@convex.com (Steve Warren) Newsgroups: comp.sys.amiga Subject: Re: Commodore and 68040 Keywords: Commodore 68040 EE TIMES Message-ID: <5068@convex.convex.com> Date: 1 Feb 90 18:01:02 GMT References: <201@modcomp.UUCP> <5623@udccvax1.acs.udel.EDU> Sender: news@convex.com Organization: Convex Computer Corporation; Richardson, TX Lines: 68 In article <5623@udccvax1.acs.udel.EDU> don@vax1.acs.udel.EDU (Donald R Lloyd) writes: > I wonder if there will ever be a 68050... a large number of >Motorola's biggest customers seem to be switching over to RISC technology. >In what direction will future Amigas go?... Well, to a large degree the 68040 *is* a RISC chip, unless you want to be a purist ;^). If you told a designer, "get as close as you can to RISC, but make it execute the 680x0 instruction set," then you would probably be most pleased if he produced something like the 68040. It has a six-level pipeline and achieves 1 cycle/instr. for the majority of instructions. That is why it beats most of the current RISC chips in performance (20 MIPS @25 MHz, ~4 MFLOPS) (assuming they are VAX- equivalent MIPS) (I know - big assumption - but perhaps not presumptuous). I think that as long as there is a 680x0 processor available with performance in the same magnitude range as current RISC processors it will continue to be utilized. A new processor architecture must be *significantly* faster to make it worthwhile to loose your software base. For a significant number of packages it would not simply be a matter of recompiling. Binary compatability is a big win for the 68040. I'm ready for my '040 LUCAS ;^). The chip is $800/sample, but you get the MMU and FPU on chip. Such a deal! ;^) I have no doubt there will be an '050, either. > ... Is there any real-world advantage >to RISC over CISC, other than being able to run lightning-fast benchmarks >to impress customers? ... Well, yes, there is, to some extent. Because the RISC processor eliminates instructions that take up disproportionate chip real-estate or require multiple cycles to execute there are these advantages: 1) Chip area that would have been used to implement sub-optimal instructions can be used for pipelining and multiple function units and extra cache, so that the extra instructions are traded for performance increases in the remaining instructions. 2) There are no multi-cycle instructions, so pipelines are less likely to get backed up by register hazards and the like. Motorola apparently did two things to overcome these advantages. 1) They went to an extremely dense process (1.2 million transisters), so that they were able to include the same performance-boosting features that smaller RISC processors include, while also including the suboptimal instructions needed for 68000 code-compatability. 2) They spent a *lot* of time analyzing and characterizing typical 680x0 applications to find out where problems would show up in the pipelines, and then implemented features that would minimize these problems. This means that the pipelines stay full most of the time. I have seen postings from several different individuals in comp.arch that indicate that RISC code is ~1.2-1.4 times as large as equivalent CISC code (due to simpler instructions). So if (as was reported) the '040 requires an average of 1.3 cycles per instruction, and executes code that is about 1.3 times denser than comparable RISC processors, it sounds to me like they are just about breaking even. But you can't drop that RISC chip into an Amiga and run Dpaint, can you? ;^) >... Aren't the Amiga's custom chips semi-RISC-ish? [...] Hmmm...the custom chip-set doesn't form a general purpose computer.