crowl@cs.rochester.edu (Lawrence Crowl) (10/11/87)
RISC Survey Articles:
Amnon Aliphas and Joel A. Feldman
"The Versatility of Digital Signal Processing Chips"
IEEE Spectrum, volume 26, number 6, pages 40-45, June 1987
Charles Gimarc and Veljko Milutinovic
"A Survey of RISC Processors and Computers of the Mid-1980s"
Computer, volume 20, number 9, pages 59-69, September 1987
Other RISC Articles:
Michael J. Flynn, Chad L. Mitchell, and Johannes M. Mulder
"And Now a Case for More Complex Instruction Sets"
Computer, volume 20, number 9, pages 71-83, September 1987
Colin B. Hunter
"Introduction to the Clipper Architecture"
IEEE Micro, volume 7, number 4, pages 6-26, August 1987
Mike Johnson
"System Considerations in the Design of the Am29000"
IEEE Micro, volume 7, number 4, page 28, August 1987
--
Lawrence Crowl 716-275-9499 University of Rochester
crowl@cs.rochester.edu Computer Science Department
...!{allegra,decvax,rutgers}!rochester!crowl Rochester, New York, 14627bcase@apple.UUCP (Brian Case) (10/12/87)
In article <3119@sol.ARPA> crowl@cs.rochester.edu (Lawrence Crowl) writes: >RISC Survey Articles: > Charles Gimarc and Veljko Milutinovic > "A Survey of RISC Processors and Computers of the Mid-1980s" > Computer, volume 20, number 9, pages 59-69, September 1987 I think a much better survey article is Patterson's "Reduced Instruction Set Computers" from CACM, Jan. 1985 (vol. 28, #1). I guess it depends on whether you want to know about RISC in general or about instantiations of RISC. I have a personal problem with Multinovic's article because it confuses the Am29000 and the Am29300 family; all the features attributed to the Am29000 are actually features of the Am29300 (a totally different beast). It is hard for me to think of the Am29300 family as a RISC since it is intended to be the core of a microcoded implmenetation....
tve@ethz.UUCP (Th. von Eicken) (10/16/87)
In article <6457@apple.UUCP> bcase@apple.UUCP (Brian Case) writes: >I have a personal problem with Multinovic's article because it >confuses the Am29000 and the Am29300 family; all the features attributed >to the Am29000 are actually features of the Am29300 (a totally different >beast). You're not alone out there. Actually, he really talks 'bout the 29300, only table 2 incorrectly reads "AMD29000". But if that only were the only bug! _ The MIPS-CO processor should be called MIPS-R2000 so that it doesn't get confused with the Stanford MIPS project. _ ARM gets wrong features attributed quite often. It doesn't "resemble the Pyramid in the sense that it employs an extremely large number of registers". It definitely has NO instruction or data cache. It has no delayed branch as far as I can tell. The interesting point, that every instruction gets executed conditionally is not mentioned altogether. _ The paragraphs on interlocks are questionnable: what are "stated software interlocks"? The software reorganization needed in MIPS, MIPS-X and MIPS-R2000 are quite different I think. Furthermore, how can others follow the "Berkeley lead (with RISC-II I suppose) by providing hardware interlocks" if RISC-II didn't have any because it doesn't need any? _ The MIPS-R2000 pipeline is quoted for complexity, I think the 6 stage CRISP pipeline with the decoded I-cache in the middle and operand forwarding from virtually every stage to every other is somewhat more complex. (No good/bad judjement intended here ...) _ The "squashed" branches in MIPS-X are also found (in a different disguise) in the ROMP which is not mentioned. _ Some nice sentences are sprinkled all over the paper. For example "Multiprocessor performance can scale linearly with the number of processors" (ugh!) or "The instruction cache is reported to have a 96 percent hit ratio". _ I like table 4 though. Converting Mhz into ns cycle times is fun! And what was the story about MIPS? I'll stop here 'cause I'm tired. I just hope I didn't make too many mistakes myself in here ... apologies if I did. Thorsten von Eicken Institute for Integrated Systems Fed. Inst. of Tech., Zurich, Switzerland tve@ethz.uucp ...!mcvax!cernvax!ethz!tve _
hildum@iris.ucdavis.edu (Eric Hildum) (10/18/87)
Just curious - how was this paper reviewed? Eric Hildum
zs01+@andrew.cmu.edu (Zalman Stern) (10/21/87)
In article <216@bernina.UUCP> tve@bernina.UUCP (Th. von Eicken) writes: >_ The "squashed" branches in MIPS-X are also found (in a different disguise) > in the ROMP which is not mentioned. How is this? I do not see the similarity between anything in the ROMP processor (the chip used in the IBM-RT) and the squashed branches discussed MIPS-X article in the proceedings of the IEEE 14th Annual International Symposium on Comp. Arch.. Could you point out what I am missing? Sincerely, Zalman Stern Internet: zs01+@andrew.cmu.edu Usenet: ...seismo!andrew.cmu.edu!zs01+ Information Technology Center, Carnegie Mellon Univ., Pittsburgh, PA 15213-3890
tim@amdcad.AMD.COM (Tim Olson) (10/22/87)
In article <0VTFpfy00Vs80TU29Z@andrew.cmu.edu> zs01+@andrew.cmu.edu (Zalman Stern) writes: +----- | In article <216@bernina.UUCP> tve@bernina.UUCP (Th. von Eicken) writes: | >_ The "squashed" branches in MIPS-X are also found (in a different disguise) | > in the ROMP which is not mentioned. | | How is this? I do not see the similarity between anything in the ROMP | processor (the chip used in the IBM-RT) and the squashed branches discussed | MIPS-X article in the proceedings of the IEEE 14th Annual International | Symposium on Comp. Arch.. Could you point out what I am missing? +----- The ROMP processor has branch and branch-with-execute instructions. The branch-with-execute instructions are of the "normal" RISC delayed branch type. The branch instructions can be used if the compiler would otherwise have to place a nop in the delayed-branch slot. I guess you could look at the branch instructions as a type of squashing, since the "delay" instruction would be executed only if the branch failed, but isn't that backwards from the MIPS-X version? -- Tim Olson Advanced Micro Devices (tim@amdcad.amd.com)
mash@mips.UUCP (10/22/87)
In article <216@bernina.UUCP> tve@bernina.UUCP (Th. von Eicken) writes: >In article <6457@apple.UUCP> bcase@apple.UUCP (Brian Case) writes: >>I have a personal problem with Multinovic's article because it >>confuses the Am29000 and the Am29300 family...... >But if that only were the only bug! >_ The MIPS-CO processor should be called MIPS-R2000 so that it doesn't get > confused with the Stanford MIPS project. Yes, that would help. >_ The paragraphs on interlocks are questionnable: what are "stated software > interlocks"? The software reorganization needed in MIPS, MIPS-X and > MIPS-R2000 are quite different I think. There are differences, but the fundametnals are quite similar. >_ The MIPS-R2000 pipeline is quoted for complexity, I think the 6 stage > CRISP pipeline with the decoded I-cache in the middle and operand > forwarding from virtually every stage to every other is somewhat more > complex. (No good/bad judjement intended here ...) Yep, CRISP is probably more complex. One of the issues omitted from the paper is that of tightly-coupled coprocessor interfaces, a topic that is, for example, critical to good FP performance. (For example, the MIPS R2010 FPU has a 6-stage pipeline to go with the R2000's 5....) >_ I like table 4 though. Converting Mhz into ns cycle times is fun! And > what was the story about MIPS? It was very hard to figure out what the MIPS numbers meant in that column. They had us (MIPS R2000) listed at 16.7MHz for 8 MIPS, which doesn't make any sense at all, since @ 12.5MHz we average 8 conservative-real-program-not-dhrystone-vax(vms/ultrix usually)-mips, and @ 16.7MHz 10-12 of those mips, depending on memory system. A bunch of the rest of the numbers seem pretty weird, either higher or lower than makes sense. (AMD is lower, CRISP seems a little higher, Spectrum higher.) A few of the numbers have imputed accuracy levels beyond reason (10.8 MIPS for Spectrum? can you tell the difference between that and 11 MIPS?) Despite all of this, it's at least good to see somebody trying to put together surveys on this information, some of which is not easy to get. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {decvax,ucbvax,ihnp4}!decwrl!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