Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site rlgvax.UUCP Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!dcdwest!ittvax!decvax!genrad!mit-eddie!godot!harvard!seismo!rlgvax!guy From: guy@rlgvax.UUCP (Guy Harris) Newsgroups: net.arch Subject: Re: Re: RISC vs VAX Message-ID: <270@rlgvax.UUCP> Date: Fri, 30-Nov-84 03:29:14 EST Article-I.D.: rlgvax.270 Posted: Fri Nov 30 03:29:14 1984 Date-Received: Sun, 2-Dec-84 05:50:10 EST References: <1839@inmet.UUCP> Organization: CCI Office Systems Group, Reston, VA Lines: 75 > (1) I said that RISCs are not suited for floating point/matrix multiplication > because: (a) attaching a floating point coprocessor to a RISC perverts > the very idea of a reduced instruction set; and (b) the original question > asked if a RISC could be produced in the same class as a VAX. No RISC > can perform every function of a 780 faster than a 780 because there are > tradeoffs made when you give up instruction set complexity for speed. > Usually floating point stuff is the first to go -- except when you make > a purely floating-point processor, in which case everything has been > given up. You can't have your floating point cake and eat it too. Anybody have any data on how a "strict RISC" (i.e., one cycle per instruction, which rules out multiply unless you have a parallel multiplier and rules out divide unless somebody has a non-iterative divide algorithm) does on jobs requiring a lot of multiplies and divides (which it has to do with library routines)? If it can do them as well as, say, an 11/780, it might be able to do software floating point as well also. Basically, think of RISC instructions as vertical microcode; if you can do it fast with vertical microcode, you can do it fast on a RISC as long as you can avoid going to memory for the instructions every time. Also, attaching a floating point coprocessor doesn't "pervert the very idea of a reduced instruction set". If you can't do FP fast on a RISC, there's no need to go to instruction set complexity except for the floating-point instructions. A RISC with an FP chip might still be faster than a (more expensive, in cost or chip real-estate or whatever) CISC. I believe a lot of the reason for a RISC is that in non-number-crunching applications a lot of the cycles go to "bureaucratic overhead" (moving things from memory/ registers into other memory/registers, testing things, etc.) and that a RISC may be able to deal with that as well as or better than a CISC. Number- crunching may have a different character (although I remember a study by Knuth of FORTRAN programs that found that a surprisingly large number of lines were exactly that kind of "bureaucratic overhead" - "j = j + 1" counts as overhead if the only purpose "j" serves is to point to an element in an array full of the numbers you're crunching); if it does, maybe a "different horses for different courses" approach would be more cost-effective. > (2) Yes, an ACIA and a VAX have different cycle times. So do a washing > machine and an ECL flip-flop. But if you build a fancy interface to > the ECL flip-flops, the washing machine still won't be able to talk > to them. Having a nice DZ-11 multiplexor on a VAx is great -- it provides > intelligent communications processing, so the VAX doesn't burn cycles > doing low-level ACIA handshaking. Now how could a RISC talk to a DZ? > Letting them share a memory space might be the best thing, but gee, > then you might need another processor to arbitrate memory accesses, and > then it starts to look like plugging a RISC into a VAX again. What? Why couldn't you plug a DZ (which, by the way, hardly provides "intelligent communications processing" in the conventional sense of the word) to a RISC? Are you worried about the DZ not being able to do a bus cycle in a reasonable amount of time, and tying the machine up twiddling its thumbs waiting for the DZ to respond so it can finish the "move" instruction that's stuffing the character into the DZ's output buffer register? Presumably you can build a bus interface chip that's as fast as the RISC, and if your bus is fast enough it won't tie the RISC up for a long time (if it isn't fast enough, it'll tie up any fast machine up too long, not just a RISC). Equating a DZ and a bus interface to a VAX-11 in complexity is bogus; the UBA on a VAX may be big, but then it does a hell of a lot more than just act as a bus interface, given its multiple data paths, and maps, and so forth and so on. > Comparing a RISC to a VAX in terms of performance, when the > RISC has two or three half- or quarter-VAXen doing its i/o, is cheating. Who says it requires a half- or quarter-VAX to do the I/O for a RISC? > Hey, my Toyota can outrace the space shuttle when you strap two solid > rocket boosters to it. Not a bad analogy; if your goal is met better by the Toyota+rocket boosters than by the space shuttle, why not go with it? If you're trying to break the land speed record, you build a land speed record car, not a jet plane with detachable wings and landing gear that can handle 700+ MPH. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy