karsh@trifolium.SGI.COM (Bruce Karsh) (11/16/88)
Why bother with reduced instruction set computers when a computer really doesn't need any instructions per se at all? At the end of the RISC road is the ZISC, Zero Instruction Set Computer. One way to look at the RISC processor design paradigm is that you should not include any feature into the design which has not been proven to be worth its implementation cost. I.e., remove extraneous features. If you are looking for something extraneous to remove from a computer's instruction set, it might be advantageous to consider removing the opcode field. The opcode takes up space in each instruction and takes time to be decoded. So let's get rid of them! But if you don't have an opcode in each instruction, how can the CPU decide which operation to apply to the operands? The selection of the operation can be determined implicitly from the address of the operands. For example, address zero can be the input to an accumulator, address 4 can be the accumulator's sum, address 8 can be the input to a multiplier, address 12 can be the multiplier's output, etc. You can even map the program counter to some memory address. By moving data into these special addresses, computation is caused to happen. These special addresses otherwise look to programs as if they were normal memory addresses. Using special addresses to control devices is not a new idea. Peripheral devices have been controlled this way for a long time. But it's interesting that you can use this control method for controlling devices within the computer as well as outside. In fact this can be the only control method that the computer has. The program for such a system would consist of a list of ordered pairs of addresses. It would execute by moving data from (for example) the first address in the pair to the second address in the pair (or vice versa). Flow of control is changed by moving data into the address mapped into the program counter. There is nothing for the instruction sequencer to do except to perform alternating fetches and stores. Therefore the instruction sequencer can be fast ... even faster than the computational units. You can acheive lots of parallelism by replicating the computational units at multiple addresses. (For instance, multiplier inputs can be located at addresses 8, 256+8, 512+8, 768+8 and multiplier outputs can be located at addresses 12, 256+12, 512+12 and 768+12). Compilers will generate code which sequences the accesses to special addresses so that they are not accessed before their computations are complete. One neat feature of this architecture is that if you consider the address ordered pairs as position vectors in cartesian space, then the program traces out a path through the space. Loops within the program appear as polygons in the space. Another neat feature is that DMA devices can get at computational units within the computer. For example, an A/D converter can be DMA'd directly into a multiply-accumulator; a list of vertices can be DMA'd directly into a matrix times vector multiplier... etc. I'v never seen a computer architecture such as this (ZISC) proposed before. I'd like to know if anybody else has suggested this idea before. -- Bruce Karsh karsh@sgi.com "Nature uses only the longest threads to weave her patterns, so each small piece of her fabric reveals the organization of the entire tapestry".
mark@hubcap.UUCP (Mark Smotherman) (11/17/88)
W.L. Van der Poel designed a ZISC in his 1956 thesis (Amsterdam, sorry no univ. ref.). Blaauw and Brooks state that he demonstrated that an operation set must provide for conditional branching, sign inversion, addition or counting, fetching and storing. Apparently he combined these functions into one instruction: subtract, store, and branch. Thus no opcode was needed. (My draft copy of the Blaauw and Brooks manuscript does not show the actual instruction.) You might be interested in looking at another of Van der Poel's designs - the Zebra (see chapter 12 of Bell and Newell, pp. 200-204). After covering the Zebra in class one day, I believe I remember Brooks saying that Van der Poel made those little wooden puzzles for a hobby and then noting the appropriateness of that hobby. -- Mark Smotherman, Comp. Sci. Dept., Clemson University, Clemson, SC 29634 INTERNET: mark@hubcap.clemson.edu UUCP: gatech!hubcap!mark
baum@Apple.COM (Allen J. Baum) (11/17/88)
[] >In article <22115@sgi.SGI.COM> karsh@trifolium.UUCP (Bruce Karsh) writes: >Why bother with reduced instruction set computers when a computer >really doesn't need any instructions per se at all? At the end of the >RISC road is the ZISC, Zero Instruction Set Computer. >The selection of the operation can be determined implicitly from the >address of the operands. For example, address zero can be the input to >an accumulator... >I'v never seen a computer architecture such as this (ZISC) proposed >before. I'd like to know if anybody else has suggested this idea >before. Not only is the idea not new, you could have bought one of these beasts about 15 years ago. The GRI-909 (I think that was the number) did essentially that. You could plug functional units into the bus, and use them, just like the standard functional units it came with. -- baum@apple.com (408)974-3385 {decwrl,hplabs}!amdahl!apple!baum
mac3n@babbage.acc.virginia.edu (Alex Colvin) (11/18/88)
In article <22115@sgi.SGI.COM>, karsh@trifolium.SGI.COM (Bruce Karsh) writes: > Why bother with reduced instruction set computers when a computer > really doesn't need any instructions per se at all? At the end of the > RISC road is the ZISC, Zero Instruction Set Computer. > > I'v never seen a computer architecture such as this (ZISC) proposed > before. I'd like to know if anybody else has suggested this idea > before. This is the Able compter by New England Digital. These are used in the Synclavier digital music synthesizers. At Dartmouth we also used them for network routers. I don't have a manual with me, but the basic idea is as you suggest. There is no opcode field. All instructions are MOVE. There are about 16 registers, two of which are PCs (one for interrupts). Memory is addressed indirectly through registers. A couple of special sources/destinations get at the ALU. There are I/O addresses as well. An interesting feature is the completely asynchronous instruction cycle. You can do a MOVE from the keyboard to the printer, which will hang the processor waiting for you to type. Needless to say, there are interrupts and status registers so you can avoid this. The processor used to be 16 bit words, TTL components. By now it's probably bigger and faster, with special interfaces to memory. There's also something else called Able, so the name may have changed. Anyone at Dartmouth or True know?
smryan@garth.UUCP (Steven Ryan) (11/18/88)
Actually a conceptual ZISC does exists. Each instruction consists of 4
address and no opcode:
<a,b,c>
Which means
MEM[a] := MEM[a]-MEM[b]
goto c if MEM[a]<0
--
-- s m ryan
+---------------------------------------+--------------------------------------+
| ....such cultural highlights as | Nature is Time's way of having |
| Alan Thicke, and, uh,.... | pausible deniability. |
+---------------------------------------+--------------------------------------+jms@antares.UUCP (joe smith) (11/23/88)
In article <22115@sgi.SGI.COM>, karsh@trifolium.SGI.COM (Bruce Karsh) writes: > Why bother with reduced instruction set computers when a computer > really doesn't need any instructions per se at all? At the end of the > RISC road is the ZISC, Zero Instruction Set Computer. > : I'v never seen a computer architecture such as this (ZISC) proposed : before. I'd like to know if anybody else has suggested this idea before. The March 1988 issue of BYTE magazine has an article on a ZISC that plugs into the Compaq 386/20 PC and costs $1999. It's called the Weitek WTL 1167 Math Coprocessor Board. You store one operand in the chip by writing to a magic location. When you write the second operand in another magic location, poof! The two floating-point numbers are added and their sum appears at a third magic location. The 80386 thinks it's simply doing load/store operations on memory that happens to have a few wait states. -- +----------------------------------------------------------------------------+ | TYMNET:JMS@F29 CA:"POPJ P," UUCP:{ames|pyramid}oliveb!tymix!antares!jms | | INTERNET: (Office-1.ARPA is no more) PHONE:Joe Smith @ (408)922-6220 | +----------------------------------------------------------------------------+
johnl@ima.ima.isc.com (John R. Levine) (11/29/88)
In article <278@antares.UUCP> jms@antares.UUCP (joe smith) writes: >[re ZISC computer] It's called the Weitek WTL 1167 >Math Coprocessor Board. You store one operand in the chip by writing to a >magic location. When you write the second operand in another magic location, >poof! The two floating-point numbers are added and their sum appears at a >third magic location. The 80386 thinks it's simply doing load/store >operations on memory that happens to have a few wait states. This is an ancient hack. The optional multiply/divide option for the original PDP-11 worked in exactly that way, by storing operands into pseudo-locations that told it what operation to perform. More recently, and apropos of another discussion here, the original optional floating point board for the RT PC worked the same way, with address bits on stores to the FPU being decoded to command the National floating point chip that did the work. -- John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 492 3869 { bbn | spdcc | decvax | harvard | yale }!ima!johnl, Levine@YALE.something Kids spend more time with their parents than parents spend with their kids.
mash@mips.COM (John Mashey) (11/29/88)
In article <2958@ima.ima.isc.com> johnl@ima.UUCP (John R. Levine) writes: >>[re ZISC computer] It's called the Weitek WTL 1167 >>Math Coprocessor Board. You store one operand in the chip by writing to a >>magic location.... >This is an ancient hack. The optional multiply/divide option for the original >PDP-11 worked in exactly that way, by storing operands into pseudo-locations >that told it what operation to perform. >More recently, and apropos of another discussion here, the original optional >floating point board for the RT PC worked the same way, with address bits >on stores to the FPU being decoded to command the National floating point >chip that did the work. Note, of course, that this is a model of the world likely to go away, for anybody who is serious about scalar floating point. The structure is only likely to happen when you have a long-cycle-count FP device, which is still fast enough to be desirable, but where the addition of a few cycles' overhead doesn't clobber the performance. As micros with tight-coupled FPUs (MIPS R3000/R3010, Moto 88K, Cypress SPARC + TI 8847) and low-cycle count operations (2-10 cycles for 64-bit add & mult) become more common, you just lose too much performance moving data around to afford that kind of interface, at least in a scalar unit. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
warren@tikal.Teltone.COM (Warren Seltzer) (12/01/88)
In the early seventies, the Burroughs 1700-series computers used this scheme for the *MICROCODE*. That is, the hardware was pretty much as you described, using registers instead of "memory", although there were other opcodes. The only code written in this machine language was microcode, diagnostic code, and research systems. As I remember, there was an "X" register, a "Y" register, and an "X+Y" register, from whence the sum was read, an "X * Y" register, an "X/Y" register, and so on. By the way, this was a very interesting machine in other ways as well. Warren -- (206) 827-9626 Warren Seltzer ...uw-beaver_____!tikal!warren Teltone Corporation .......fluke___/ P.O. Box 657 ...microsoft__/ Kirkland, WA 98033