bcase@amdcad.UUCP (07/18/86)
>Actually, from my perspective, one of the main objectives of a RISC is the >simplification of the hardware so that you can fit more other things on >the chip, i.e., caches or whatever, that could potentially have a greater >impact on the overall system performance than your fancy-dancy instructions. Er, RISC machines are not necessarily built around single-chip CPUs. The benefits of a RISC approach can be realized in any technology. >Certainly, you don't want to do anything that makes it impossible to generate >code, but in terms of what you put in or what you take out, I'd say that >the hardware of the implementation is the highest consideration. Maybe I'm >very mistaken, but you'd have to work long and hard to convince me that >the removal of inter-pipeline interlocks, the addition of the deferred >jump feature or fixed length instructions simplify code generation or >assembly language programming. They are only there because they simplify >the hardware required to take out jump penalties or they were something >that a compiler could "work around" and therefore wasn't required in >the hardware. ARRRGGG! Ok, I don't really want to "work long and hard," so I'll try to work lazily and for a short duration: The consideration of the needs and capabilities of optimizing compilers (and operating systems and the behavior of applications) is at least as important as the consideration of the capabilities and limitations of the processor implementation technology. True, fewer inter-pipeline interlocks and a deferred-jump feature are there (if they are there, these features are not found in all RISC processor architectures) for hardware reasons; however, these are not the essential RISC ideas at all! The essential RISC idea (at least I think John Cocke would agree) is that: instructions should not bind together operations which an optimizing compiler (or other program generator, e.g. human being) might (read: probably will) otherwise choose to separate in order to produce a more efficient (read: more quickly executing) program. In fact, what a compiler wants in an architecture is (at least) the following: instructions which have predictable costs (in execution time and in size (helps in choosing the fastest sequence)), instructions which do not bind together operations which the compiler might like to separate (note that addressing modes in general violate this principle), and registers which are not characterized (i.e. all registers general purpose). It just happens that if all instructions are the same length, purpose). It just happens that if all instructions are the same length, (e.g., move ahead/back up a certain number of instructions; yes, I know we all want high-level debuggers, but they still might have to do this kind of operation even if the user never sees it). Anyway, my point is that optimizing compilers (and other system software components) want RISC architectures as targets. I would claim that most hardware guys (gals?) also want RISC architectures as targets. Oops, looks like I worked long and hard after all and still may not have constructed a convicing argument. >And my last word, my firm belief is that any processor designed without >any (or a very small) consideration to either the software that the >thing is going to run, OR the hardware implementation that is required >to execute the instructions is doomed to failure. And this includes >processors that are designed by compiler writers living in a vacuum. >-- >Ken Shoemaker, Microprocessor Design, Intel Corp., Santa Clara, California Yeah, I agree. But don't say things that imply that RISC concepts are only valid in the single-chip CPU domain or that hardware is the main consideration. The processor core of the INMOS transputer was designed (ok, I am guessing here, but I think I am right (obviously, why else would I write it?)) to take up as little space as possible. However, I believe that most optimizing compiler writers would have argued for a larger register set instead of the stack architecture. The point of RISC (as I see it) is not to make hardware or software *easier*; instead, the point is to make the hardware and software *better* (i.e. create the highest performance system possbile; yes, I know this isn't the only measure of "betterness", but it is a concrete one at least). One may work awfully "long and hard" at a RISC design. bcase Sung to the tune of "Timewarp:" It's just a shift the left, And then a shift to the ri-i-ight! Get a load of those MIPS And the code's right ti-i-ght! This lock-step pipeline Really drives me insa-a-a-e-a-ane Let's do the pre-charge again!