Path: utzoo!mnetor!uunet!steinmetz!sunset!oconnor
From: oconnor@sunset.steinmetz (Dennis M. O'Connor)
Newsgroups: comp.arch
Subject: Re: RPM-40 microprocessor @ 40 MHz; data from ISSCC
Message-ID: <9678@steinmetz.steinmetz.UUCP>
Date: 25 Feb 88 05:19:03 GMT
References: <9651@steinmetz.steinmetz.UUCP>
Sender: news@steinmetz.steinmetz.UUCP
Reply-To: sunset!oconnor@steinmetz.UUCP
Organization: GE Corporate R&D Center
Lines: 82

An article by zs01+@andrew.cmu.edu (Zalman Stern) says:
] There are a few things I don't quite get about the RPM-40 info posted here 
] recently. Maybe somebody can clarify these for me.
] 
] First, in the "DARPA MIPS core ISA", which binding does "MIPS" take? Is this 
] MIPS the corporation, MIPS the Stanford research project, or MIPS the
] vacuous abbreviation?

None of the above, sort of. Closest is the Stanford research project.
It has the same (overly cute and contorted :-) meaning here as it did
there :	Microprocessor (without) Interlocked PipestageS. It really is
a historical refernce to the original Stanford work, which inspired
the DARPA program. And also birthed MIPS, Inc.

] In some instructions, it appears that the second register argument is only 4 
] bits long. Does this limit one to the first 16 registers or am I missing 
] something? Can this be extended with a PREFIX instruction even
] though it isn't an immediate operand?

Yes, this limits the non-destination register to be one of R0 through
R15.Usually. There are exceptions, mainly two instructions that reverse
which register is considered the destination.

] Could you post the ALU opcodes available? Notably do they include
] multiply an divide? (I know this is probably a stupid question.)

At this time, I can clarify anything presented at ISSCC. I am not sure
I can divulge new information. Sorry, not my decision to make.
But the multiply/divide support is NOT a stupid question. Beleive me,
we thought of maybe four fundamentally different approaches before
picking the fastest one we could affords to implement in the system.
Maybe more details later ...

] How does a coprocessor load work? Does the main processor calculate the 
] address and then tell the coprocessor to pick up the data off the bus
] when it arrives? 

Yes, and also tells the coprocessor which register to put it in.

[ ... some stuff I'm unsure about responding to omitted ... ]

] I find this a very interesting architecture. My first impression is
] that the prefix instruction makes the 16 bit instructions reasonable.
] (A big win in my opinion.) It is rather like having an extra register
] for holding immediate operands only. I guess it might complicate
] exception handling though.

Thanks for the complement. WE like it too. PREFIX instructions, BTW,
is adapted from the InMOS transputer concept of building instructions
a byte at a time. IT's essentially a simplified version. An
interesting point : it makes the RPM40 instruction set totally
oblivious to data word size. The registers could be any number of
bits, and the instruction set would cope gracefully. It also makes the
instruction set "context independent", a feature of MANY if not ALL
RISC architectures : once you have an instruction in hand, you don't
need to know where it came from to know what it is. This is unlike,
say, the VAX and 68K families, which have immediate values imbedded
within the instruction stream which are only distinguishable if the
previous "instruction" word is known. Makes dis-assembly tougher.
Probably makes instruction decoding tougher too.

Back to PREFIX : using our PREFIX scheme, we handle commonly occuring
small constants quickly, and larger constants more slowly, but without
using additional user-visible resources. The cost of a large constant
is "step-wise proportional" to the constants length in bits.  Given
what we could find in the research about constants, this is the
correct "RISC philosophy" thing to do.

All you 32-bit instruction advocates : how many of your 32-bits of
instruction are usually wasted ( like by leading zeroes or ones, or
unused register specifications ) ? If it sounds like I'd welcome a
debate on the merits of 16 vs 32 bit instructions : sure. Isn't that
what comp.arch is for ? And I said a DEBATE, not a fire-fight :-)

] Sincerely,
] Zalman Stern


--
	Dennis O'Connor 	oconnor@sunset.steinmetz.UUCP ??
				ARPA: OCONNORDM@ge-crd.arpa
    "Nuclear War is NOT the worst thing people can do to this planet."