Path: utzoo!attcan!uunet!know!zaphod.mps.ohio-state.edu!sdd.hp.com!ucsd!ucrmath!rhyde From: rhyde@ucrmath.ucr.edu (randy hyde) Newsgroups: comp.sys.apple2 Subject: Re: RISC Machines Message-ID: <9057@ucrmath.ucr.edu> Date: 4 Oct 90 15:56:22 GMT References: <0093D934263990A0.00000110@dcs.simpact.com> <1990Oct2.155706.16241@mintaka.lcs.mit.edu> <14007@smoke.BRL.MIL> <14009@smoke.BRL.MIL> Organization: University of California, Riverside Lines: 50 >> Apples and oranges (RISC vs. CISC) "C" code. Throwing out code (this is a warning to both sides of this arguement) proves nothing. First we had someone comparing the output of a C compiler on the SPARC against hand written 6502 code. Now we're comparing SPARC code against ORCA C output. None of this is particularly valid. 1) The SPARC C compiler is a highly optimizing compiler (all RISC compilers have to be optimizing or the generated code would really suck). 2) ORCA/C is not very good at straight code generation, much less optimiz- ation. Therefore, comparing the outputs of two compilers to show how the 6502 is better than the SPARC (or vice versa) is a worthless exercise. All you're showing is that Sun's compiler is better than Byteworks'. I don't think anyone argues this point. 3) Comparing assembly language code isn't particularly valid either. I know of no one who writes in SPARC assembly code. I'm sure there are such creatures, but they are few and far inbetween. Lots of people, however, write in 6502/65816 assembly language. This, BTW, is a point in favor of comparing 6502 assembly against the output of a SPARC C compiler. 4) Comparing 6502 assembly against SPARC anything does not show that the 6502 is CISC or RISC. It simply demonstrates that the 6502 has a different architecture. If you compared SPARC against 29000, MIPS 3000, or the Transputer, you could reach similar conclusions to comparing 6502 against SPARC (okay, so I'm stretching it a little here). Having talked to some other individuals on BIX (who are a little more up on the subject than I), here's the conclusion I've come to concerning RISC. RISC stands for (REDUCED INSTRUCTION) Set Computer; not (REDUCED INSTRUCTION SET) Computer. A RISC machine does not necessarily have a small number of instructions (RIS)C, although most do. Instead, the activities performed by the CPU for each instruction are limited, i.e., each individual instruction is reduced to the bare minimum (i.e., (RI)SC). If you view an arithmetic or logical operation as one operation, and accessing memory as one operation, then a typical 6502 instruction like ADD ABS requires two operations: (1) accessing memory to get the value, and (2) adding this value to Acc. A RISC architecture only allows (in the pure sense) one operation. That's why they have a load/store architecture. You load ABS into a register (one operation) and then ADD that register to Acc (the second operation). By this definition the 6502 fails miserably as a RISC. Only about 1/2 of the instructions are single operation instructions (about the same as the 8086, I might point out). *** Randy Hyde Hopefully, this helps put the "6502 as RISC" question to bed. Flame all you want, but raising your voice does not change the truth.