stuart@speedy.cs.wisc.edu (Stuart Friedberg) (10/19/88)
Once upon a time, ... In article <5498@juniper.uucp> Christopher Michael Whatley writes: >They are supposedly developing their own RISC chip that is compatible with the >030. I don't know any more than that. I read this in a rumour column. In response, ... In article <5941@winchester.mips.COM> John Mashey writes: > This defies all logic. > a) If it's compatible with an 030, it's not a RISC. I agree with John, completely. In article <737@jetsun.WEITEK.COM> Krishnan Sridhar writes: > Not quite true. A RISC version of 68K can be made and with > appropriate compiler, can be made fully compatibile with their ancestors. By Krishnan's argument, all we need to make the 6502 "fully compatible" with a 370 is "an appropriate compiler." I guess Krishnan means they can run the same portable C programs. But that's NOT fully compatible. If the rumored CPU's instruction set (*I*nstruction *S*et is fully half of the acronyms RISC and CISC) is not a strict superset of the MC680X0's instruction set, then the rumored CPU is not fully compatible with the MC680X0. By any sane usage of the term "RISC", a strict superset of the MC680X0's instruction set would NOT be a RISC instruction set. Ergo, I agree with John, it defies all logic to say such a thing. (However, marketing people do it all the time!) If we accept *software* compatibility as our goal, then we don't have to care very much at all about hardware compatibility. Please witness the orderly migration from Sun-2's and Sun-3's (based on MC680X0) to Sun-4's (based on SPARC). The SPARC is NOT fully compatible with a MC680X0. But none of the old portable software cares one whit. (Some of the new software has new bugs, but that's not the processor's fault.) Frankly, the rumor was stupid, should have been dismissed out of hand, and certainly was not deserving of this much attention. Stu Friedberg (stuart@cs.wisc.edu)
daveh@cbmvax.UUCP (Dave Haynie) (10/20/88)
in article <6496@spool.cs.wisc.edu>, stuart@speedy.cs.wisc.edu (Stuart Friedberg) says: > Summary: risc mc68020, ho-ho-ho > Once upon a time, ... > In article <5941@winchester.mips.COM> John Mashey writes: >> This defies all logic. >> a) If it's compatible with an 030, it's not a RISC. > I agree with John, completely. For an example of an architecture that's 68000 compatible and RISCy to the point of executing most instructions in a single clock cycle, look no farther than the Edge computer. However, if you want this on a single chip, instead of a bunch of gate arrays, you'll have to wait. > In article <737@jetsun.WEITEK.COM> Krishnan Sridhar writes: >> Not quite true. A RISC version of 68K can be made and with >> appropriate compiler, can be made fully compatibile with their ancestors. > By Krishnan's argument, all we need to make the 6502 "fully compatible" > with a 370 is "an appropriate compiler." I guess Krishnan means they > can run the same portable C programs. But that's NOT fully compatible. That's not a good argument, but it doesn't mean that you can't have a CPU that exploits RISC concepts (all that any RISC chip does, since there is no single definition of RISC) and also executes unmodified 680x0 object code. Perhaps only 25% of the instructions would execute in a single clock cycle, and perhaps a compiler could reorder to keep the pipeline full. So old code runs on the new machine with a 50% speedup. Recompile it, and maybe you go 100% faster. Take that new code, run it on a 68030, and it might go slower. > By any sane usage of the term "RISC", a strict superset of > the MC680X0's instruction set would NOT be a RISC instruction set. It certainly wouldn't be a load/store architecture, which is one of the many RISC design goals. Given large enough silicon, it COULD be completely hard-wired, another RISC design goal. Consider that most of the RISCy CPUs on the market have been done as little baby chips, by ASIC houses (SPARC, MIPS). A real IC design house may surprise you with what they can do using RISC concepts, given enough time. The 88x00 family doesn't count; even though Motorola did design it, they didn't use normal VLSI design techniques on the chip, instead opting for much the same simplicity found in other chips. While that leads to faster design cycles and even earlier implementations in new technologies (since you'll certainly be seeing 10,000 gate GaAs chips before 100,000 gate GaAs chips), it isn't the only answer. > If we accept *software* compatibility as our goal, then we don't have > to care very much at all about hardware compatibility. Please witness > the orderly migration from Sun-2's and Sun-3's (based on MC680X0) to > Sun-4's (based on SPARC). The SPARC is NOT fully compatible with a > MC680X0. But none of the old portable software cares one whit. (Some > of the new software has new bugs, but that's not the processor's fault.) SPARC wasn't designed to be 680x0 compatible, except in the most portable of source levels senses. They didn't really care all that much. Others do. > Frankly, the rumor was stupid, should have been dismissed out of hand, > and certainly was not deserving of this much attention. That I'll agree. Neither NeXT nor anyone else using ASICs is going to out-design Motorola in the 680x0 family, it's just too complicated. > Stu Friedberg (stuart@cs.wisc.edu) -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy "I can't relax, 'cause I'm a Boinger!"