mark@mips.COM (Mark G. Johnson) (02/25/88)
To perhaps clarify what the ISSCC speaker claimed for performance on the GE "RPM-40" integer unit, here is a more extensive quotation of his presentation: ......................................................................... "We have demonstrated a wire-wrap board with this in, running at 40 MHz, and we have a peak rate of 40 MIPS, of CPU instructions." "Somebody's going to ask, `What's that in real MIPS ?' We have done a comparison between this instruction set and this architecture on the 1750A DAIS MIPS (which is a standard Air Force mix of instructions) and our most pessimistic value on that is 14 MIPS." "We compare that with the best machines around and we're talking about at least a two or three to one speedup when using this technique --- although it's not a 1750, don't run away with that idea." ......................................................................... Now, what was meant by _the_best_machines_around_ ?? Possibilities include: 1. The other CORE-MIPS contractors (Unisys, McDonnell, TI) 2. Mil-spec 1750A machines running the DAIS mix 3. Mil-spec 68020's or 80286's with no wait states 4. Top end VAX (8800?) emulating the DAIS mix 5. IBM and Amdahl machines emulating the DAIS mix 6. Cyber-190 or Cray-2 on integer code To me, (2.) seems most likely, as this would imply a performance of 4.7 - 7 MIPS for existing mil-spec 1750A processors (on the DAIS mix). It would also be the sort of military-embedded-computer vs. military-embedded-computer comparison that would be most interesting to the RPM-40's potential customers. Machines 4-6, which arguably include some of "the best machines around" for running operating systems and/or integer programs, aren't optimized to fit in the nosecone of a missile, fly through clouds of radiation, and run an Ada program to "track the BadGuy, collide with him, & go Bang". -- MJ
oconnor@sunset.steinmetz (Dennis M. O'Connor) (02/25/88)
An article by mark@mips.COM (Mark G. Johnson) says:
] To perhaps clarify what the ISSCC speaker claimed for
] performance on the GE "RPM-40" integer unit, here is a
We call it the CPU. It can (and is) function quite nicely (IMHO :-)
by itself, but is designed to work with the FPU and ... another thing.
] more extensive quotation of his presentation:
] "Somebody's going to ask, `What's that in real MIPS ?' We have
] done a comparison between this instruction set and this
] architecture on the 1750A DAIS MIPS (which is a standard Air
] Force mix of instructions) and our most pessimistic value on
] that is 14 MIPS."
]
] "We compare that with the best machines around and we're talking
] about at least a two or three to one speedup when using this
] technique --- although it's not a 1750, don't run away with
] that idea."
The speaker, I think, was David K. Lewis of GE's Electronic Laboratory,
one of the system architects and the head of the CPU effort. Let's be
sure credit is given where due. (THIS IS NOT A FLAME, REALLY !)
] Now, what was meant by _the_best_machines_around_ ?? Possibilities
] include:
] 1. The other CORE-MIPS contractors (Unisys, McDonnell, TI)
We and Unisys worked essentially "blind" to each other. So we don't
know what their performance is, and they haven't said, yet. Comparison
to the GaAs micros (McD, TI/CDC) is inappropriate, as they are not in
the same development time-frame,last I heard.
] 2. Mil-spec 1750A machines running the DAIS mix
] 3. Mil-spec 68020's or 80286's with no wait states
This is kinda it. What it really means is "two or three times
the best DAIS performance anybody else has yet claimed". With the
qualifications you mention later on : embedded-micros.
] 4. Top end VAX (8800?) emulating the DAIS mix
] 5. IBM and Amdahl machines emulating the DAIS mix
] 6. Cyber-190 or Cray-2 on integer code
( Humor mode ) Yes, this is it : we're twice as fast as a CRAY-2 on
the DAIS mix. And it comes in a 64 pin DIP, draws only 250mW, and
costs only $19.95 in quantity ten. Uh, cash in advance ONLY ... :-)
] To me, (2.) seems most likely, as this would imply a performance of
] 4.7 - 7 MIPS for existing mil-spec 1750A processors (on the DAIS mix).
Best number I'd heard from a REAL 1750A was 2 DAIS MIPS, for
Performance Semiconductor's 20MHz CMOS chip.
] It would also be the sort of military-embedded-computer vs.
] military-embedded-computer comparison that would be most interesting
] to the RPM-40's potential customers. Machines 4-6, which arguably
] include some of "the best machines around" for running operating systems
] and/or integer programs, aren't optimized to fit in the nosecone of a
] missile, fly through clouds of radiation, and run an Ada program
] to "track the BadGuy, collide with him, & go Bang".
( Side note : if you can collide with the BadGuy at orbital-intercept
relative-velocities, it is not neccesary that you also go "Bang" :-)
Your dead on target. RPM40 is NOT a VAX-killer or SUN competitor. Here
at GE, we don't compare Massey-Fergussen 1500-horsepower tractors to
nitrobenzene-burning top-fuel funny cars.
It would be tough to build a micro that would be best for everyone.
What's more important, throughput or latency ? Speed or power ?
System package count or package pin count ? We tried to design the
best little embedded-system micro we could (within contract
constraints) and we think we did a good job. Hey, but criticize it,
please : I'd like the next one to be EVEN BETTER !
] -- MJ
--
Dennis O'Connor oconnor@sunset.steinmetz.UUCP ?
ARPA: OCONNORDM@ge-crd.arpa
(-: The Few, The Proud, The Architects of the RPM40 40MIPS CMOS Micro :-)davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (02/26/88)
In article <9679@steinmetz.steinmetz.UUCP> sunset!oconnor@steinmetz.UUCP writes: | [... technical detail omitted ...] | | Your dead on target. RPM40 is NOT a VAX-killer or SUN competitor. Here | at GE, we don't compare Massey-Fergussen 1500-horsepower tractors to | nitrobenzene-burning top-fuel funny cars. Mind you, there are some of us who would like this chip in a workstation, but it would have to be done in quantity to keep the cost of the chipset down. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
mash@mips.COM (John Mashey) (02/27/88)
In article <9689@steinmetz.steinmetz.UUCP> davidsen@crdos1.UUCP (bill davidsen) writes: >In article <9679@steinmetz.steinmetz.UUCP> sunset!oconnor@steinmetz.UUCP writes: >| [... technical detail omitted ...] >| >| Your dead on target. RPM40 is NOT a VAX-killer or SUN competitor. Here >| at GE, we don't compare Massey-Fergussen 1500-horsepower tractors to >| nitrobenzene-burning top-fuel funny cars. > >Mind you, there are some of us who would like this chip in a >workstation, but it would have to be done in quantity to keep the cost >of the chipset down. I assume this must be humorous: it is obvious that this architecture was designed to be a microcontroller, to run limited-size, embedded, and definitely, non-UNIX applications. It seems OK for that purpose, but it obviously wasn't built for running UNIX or large applications (and there's nothing wrong with that). -- -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
jesup@pawl18.pawl.rpi.edu (Randell E. Jesup) (02/29/88)
In article <9679@steinmetz.steinmetz.UUCP> sunset!oconnor@steinmetz.UUCP writes: >The speaker, I think, was David K. Lewis of GE's Electronic Laboratory, >one of the system architects and the head of the CPU effort. Let's be >sure credit is given where due. (THIS IS NOT A FLAME, REALLY !) Dave is REALLY sharp. Even if he does have an English accent. :-) >Your dead on target. RPM40 is NOT a VAX-killer or SUN competitor. Here >at GE, we don't compare Massey-Fergussen 1500-horsepower tractors to >nitrobenzene-burning top-fuel funny cars. Awww. Not that it _couldn't_ be a sun-competitor..... But I would rather doubt GE using it for that, though anything's possible, especially if one has enough money to interest GE. > Dennis O'Connor oconnor@sunset.steinmetz.UUCP ? // Randell Jesup Lunge Software Development // Dedicated Amiga Programmer 13 Frear Ave, Troy, NY 12180 \\// beowulf!lunge!jesup@steinmetz.UUCP (518) 272-2942 \/ (uunet!steinmetz!beowulf!lunge!jesup) BIX: rjesup (-: The Few, The Proud, The Architects of the RPM40 40MIPS CMOS Micro :-)
davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (02/29/88)
In article <1695@winchester.mips.COM> mash@winchester.UUCP (John Mashey) writes: | In article <9689@steinmetz.steinmetz.UUCP> davidsen@crdos1.UUCP (bill davidsen) writes: | > [..] | >Mind you, there are some of us who would like this chip in a | >workstation, but it would have to be done in quantity to keep the cost | >of the chipset down. | | I assume this must be humorous: it is obvious that this architecture was | designed to be a microcontroller, to run limited-size, embedded, | and definitely, non-UNIX applications. It seems OK for that purpose, | but it obviously wasn't built for running UNIX or large applications | (and there's nothing wrong with that). Nope. It runs a general purpose instruction set, it has lots of power, and RISC machines are not too bad as targets for UNIX ports. Looks like the speed would be 2-6 times the Sun (25MHz) machines, depending on implementation. I don't think it's a microcontroller in the usual sense, with a lack of general instructions and registers, and limited word size. There was NO smiley face on my posting, and not on this one either. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
oconnor@sunset.steinmetz (Dennis M. O'Connor) (03/01/88)
An article by mash@winchester.UUCP (John Mashey) says: ] In article <...> davidsen@crdos1.UUCP (bill davidsen) writes: ] >In article <...> sunset!oconnor@steinmetz.UUCP writes: ] >| Your dead on target. RPM40 is NOT a VAX-killer or SUN competitor. Here ] >| at GE, we don't compare Massey-Fergussen 1500-horsepower tractors to ] >| nitrobenzene-burning top-fuel funny cars. ] > ] >Mind you, there are some of us who would like this chip in a ] >workstation, but it would have to be done in quantity to keep the cost ] >of the chipset down. ] ] I assume this must be humorous: it is obvious that this architecture was ] designed to be a microcontroller, to run limited-size, embedded, ] and definitely, non-UNIX applications. It seems OK for that purpose, ] but it obviously wasn't built for running UNIX or large applications ] (and there's nothing wrong with that). ] -- ] -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> Uh, gee, I don't know. Seems to me it has everything it needs to support UNIX. It supports page faults, has a secure (we hope) supervisor mode, some built-in address space management, a 8 gigabyte total address space, software traps ... gee, just about everything a 68010 has, even vectored interupts. What specifically does it lack that indicates it wasn't built for UNIX ? What it wasn't was OPTIMIZED for UNIX. It's OPTIMIZED for the embedded computing environment. You know, like BM/CCC and cruise missiles. Like AEGIS, SUBACS, Star Wars, and that stuff. Not trivial, you bet. Calling it a microcontroller, well, that seems kind unfair. It may not be able to run UNIX as fast as another 40MIPS machine that was more UNIX-oriented, true. :-) But the minimum functionality to support a multi-tasking operating system is there. Mainly because we think that the embedded world may head this way. Someday. When Ada compilers can be trusted, I guess. LIMITED SIZE ? Well, for now, maybe, but there's no reason that eventually the entire 8 gigabytes of space afforded by the architecture cant be (at least virtually) available. Well, I guess now that you mention it, 8 gigabytes IS a limit. :-) If I didn't put enough smileys in this, please add your own. :-) -- Dennis O'Connor UUNET!steinmetz!sunset!oconnor ARPA: OCONNORDM@ge-crd.arpa (-: The Few, The Proud, The Architects of the RPM40 40MIPS CMOS Micro :-)
mash@mips.COM (John Mashey) (03/01/88)
In article <9732@steinmetz.steinmetz.UUCP> sunset!oconnor@steinmetz.UUCP writes: > >Uh, gee, I don't know. Seems to me it has everything it needs to >support UNIX. It supports page faults, has a secure (we hope) >supervisor mode, some built-in address space management, a 8 gigabyte >total address space, software traps ... gee, just about everything a >68010 has, even vectored interupts. What specifically does it lack >that indicates it wasn't built for UNIX ? I didn't really mean to fire up an argument, because I thought I was agreeing with what people said it was. But, if people want to claim that it's a good UNIX engine, it would be nice to know: a) How you use the MMU to do a modern UNIX? b) How you turn the SRAM into a cache, because NOBODY cares about a workstation whose memory is limited to the size of SRAM you can drive off the CPU? (and what the performance hit is?) c) How much of a performance hit one takes from the various design choices when trying to use it in the general environment? d) Any benchmark numbers at all, for real programs of substance, even run on simulators? Can't we EVER get some real numbers? >What it wasn't was OPTIMIZED for UNIX. It's OPTIMIZED for the embedded >computing environment. You know, like BM/CCC and cruise missiles. >Like AEGIS, SUBACS, Star Wars, and that stuff. Not trivial, you bet. >Calling it a microcontroller, well, that seems kind unfair. Nobody thinks of these as trivial applications. "Microcontroller" was not meant as a pejorative, rather as distinguishing it from micros aimed more at more general-purpose environments. Suggest another term; I think microcontrollers are fairly smart these days. >It may not be able to run UNIX as fast as another 40MIPS machine that >was more UNIX-oriented, true. :-) But the minimum functionality to >support a multi-tasking operating system is there. Mainly because we >think that the embedded world may head this way. Someday. When Ada >compilers can be trusted, I guess. Just out of curiosity, is the RPM intended for ADA, or C, ... or assembler? >LIMITED SIZE ? Well, for now, maybe, but there's no reason that >eventually the entire 8 gigabytes of space afforded by the >architecture cant be (at least virtually) available. Well, >I guess now that you mention it, 8 gigabytes IS a limit. :-) -- -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
mash@mips.COM (John Mashey) (03/01/88)
In article <9721@steinmetz.steinmetz.UUCP> davidsen@crdos1.UUCP (bill davidsen) writes: ... >Nope. It runs a general purpose instruction set, it has lots of power, >and RISC machines are not too bad as targets for UNIX ports. Looks like >the speed would be 2-6 times the Sun (25MHz) machines, depending on >implementation. As noted elsewhere, the design as presented has 2 obvious problems for UNIX: people would happily hear why they are not so: a) The MMU b) The use of SRAM as THE memory, not cache, and the limits thereof. I'd assume that with a major bunch of external logic, and some performance hits, you can probably work around these, but why? c) Can we get numbers to back up the 2-6? d) Does it have software? (Note: 2-6X a Sun-3/260 is competitive, or at least the 4-6 part is, if it's delivered in a system with a solid UNIX with good compilers, at least C, FORTRAN, ADA within the next 6 months) > >I don't think it's a microcontroller in the usual sense, with a lack of >general instructions and registers, and limited word size. There was NO >smiley face on my posting, and not on this one either. Microcontrollers (to me) are VLSI micros tuned in different directions from more general-purpose micros. I'd happily hear a different term, like microprocessor-tuned-for-embedded-systems, or whatever. Many of the general-purpose RISC micros are tuned very differently, i.e., caches, MMUs geared to demand-paging, high-level language orientation, etc. -- -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
oconnor@sungoddess.steinmetz (Dennis M. O'Connor) (03/02/88)
An article by mash@winchester.UUCP (John Mashey) says:
] In article <...> sunset!oconnor@steinmetz.UUCP writes:
] > [...] What specifically does it lack
] >that indicates it wasn't built for UNIX ?
]
] But, if people want to claim that it's a good UNIX engine,
] it would be nice to know:
] a) How you use the MMU to do a modern UNIX?
It doesn't have an MMU : it has a "process address space" scheme.
You have to add a full MMU if you want one, just like a MC68010
] b) How you turn the SRAM into a cache, because NOBODY cares about
] a workstation whose memory is limited to the size of SRAM you
] can drive off the CPU? (and what the performance hit is?)
Go back to the original reason for inventing caches. A cache,
originally, was INDISTINGUISHABLE from main memory to the CPU.
So what's the problem with substituting a cache-backed-up-with-DRAM
for the high-speed RAM that's there ?
] c) How much of a performance hit one takes from the various
] design choices when trying to use it in the general environment?
] d) Any benchmark numbers at all, for real programs of substance,
] even run on simulators? Can't we EVER get some real numbers?
I didn't know it was benchmarks that made an architecture suitable
for UNIX. :-) Benchmarks are by nature a MEASURE, not a property,
of a computer architecture's suitablility to a problem. And remember,
no matter where you go, "Lack of Proof is Not Proof of Lack." WE did
NOT claim it WAS a good UNIX box; YOU claimed it WASN'T. All that
anyone at GE did ( Bill Davidsen in fact, not one of the RPM40 team,
but a person with fair knowledge of the project ) was express a
DESIRE to see the RPM40 in a "UNIX box". So the burden of proof is
on YOU to back up your claim that it isn't suited to one.
] Just out of curiosity, is the RPM intended for ADA, or C, ... or assembler?
Ada, which is NOT an acronym, and therefor should not be in all-caps.
But this is a picky point, which you probably knew, eh ? Ada is a
registered trademark of the U.S. Goverment - Ada Joint Program Office.
Yes, there WHERE design decisions that resulted from this choice.
] -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc>
--
Dennis O'Connor UUNET!steinmetz!sunset!oconnor
ARPA: OCONNORDM@ge-crd.arpa
(-: The Few, The Proud, The Architects of the RPM40 40MIPS CMOS Micro :-)sah@mips.COM (Steve Hanson) (03/05/88)
>]An article by mash@winchester.UUCP (John Mashey) says: >In article <9759@steinmetz.steinmetz.UUCP> sungoddess!oconnor@steinmetz.UUCP writes: >] Just out of curiosity, is the RPM intended for ADA, or C, ... or assembler? >Ada, which is NOT an acronym, and therefor should not be in all-caps. >But this is a picky point, which you probably knew, eh ? Ada is a >registered trademark of the U.S. Goverment - Ada Joint Program Office. >Yes, there WHERE design decisions that resulted from this choice. > >] -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> > >-- > Dennis O'Connor UUNET!steinmetz!sunset!oconnor > ARPA: OCONNORDM@ge-crd.arpa > (-: The Few, The Proud, The Architects of the RPM40 40MIPS CMOS Micro :-) Ada is no longer a registered trademark of the U.S. Government. The Ada Joint Program Office announced the the Federal registration of Ada as a trademark will not be maintained after November 30, 1987. Can you elaborate on what RPM-40 architectural design decisions were made to support Ada?
jesup@pawl23.pawl.rpi.edu (Randell E. Jesup) (03/05/88)
In article <1731@winchester.mips.COM> mash@winchester.UUCP (John Mashey) writes: >But, if people want to claim that it's a good UNIX engine, >it would be nice to know: > a) How you use the MMU to do a modern UNIX? > b) How you turn the SRAM into a cache, because NOBODY cares about > a workstation whose memory is limited to the size of SRAM you > can drive off the CPU? (and what the performance hit is?) > c) How much of a performance hit one takes from the various > design choices when trying to use it in the general environment? I think the answer to most of these questions would be an external cache/mmu chip(s). I really wish I could say more about this, let it stand that these considerations were most definitely part of the overall system design, and more than a bit of research was done to find the answers. >Just out of curiosity, is the RPM intended for ADA, or C, ... or assembler? Well, I's bet on Ada, and maybe C or pascal. In fact, the whole Core ISA idea was to have compilers that generate Core, and then use each processors backend software to translate it into native assem and reorganize it. One reason for the lack of lots of benchmarks: no really good Core ISA compilers. I'm not sure about the present, but when I was working on it we had the MIPS pascal compiler (yes, MIPS Inc was involved in the Core ISA project). They added a Mips->Core translator, which produced pretty poor (and often wrong/illegal) Core ISA. RISC compilers are supposed to be GOOD optimizing compilers, so any numbers from the pascal compiler would be skewed. This isn't to impune the compiler per se, but mainly the translator. Remember this is a mutli-company government research project, not an attempt to take over the micro-RISC world, so GE hasn't thrown dozens of programers at compilers/utilities/benchmarks the way CPU-sellers do. Hopefully by now there are some good compilers, but I wouldn't know, as I no longer am consulting there. >-john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> I think these issues have been beaten to death. Anyone want a new subject, like reorganizing algorithms? (my specialty :-) Is there anyone else out there that does linking before reorganization? Or given thought to doing optimal (instead of near-optimal) reorganization in small code blocks? // Randell Jesup Lunge Software Development // Dedicated Amiga Programmer 13 Frear Ave, Troy, NY 12180 \\// beowulf!lunge!jesup@steinmetz.UUCP (518) 272-2942 \/ (uunet!steinmetz!beowulf!lunge!jesup) BIX: rjesup (-: The Few, The Proud, The Architects of the RPM40 40MIPS CMOS Micro :-)
jesup@pawl23.pawl.rpi.edu (Randell E. Jesup) (03/05/88)
In article <1732@winchester.mips.COM> mash@winchester.UUCP (John Mashey) writes: > b) The use of SRAM as THE memory, not cache, and the limits > thereof. I'd assume that with a major bunch of external logic, > and some performance hits, you can probably work around these, but why? There was much thought about external caches (the system targets may require much more than 128K memory). > d) Does it have software? (Note: 2-6X a Sun-3/260 is competitive, > or at least the 4-6 part is, if it's delivered > in a system > with a solid UNIX > with good compilers, at least C, FORTRAN, ADA > within the next 6 months) As has been said in GE management many times, "GE is not in the computer business!" (Outgrowth of the old GE/Honeywell fiasco) Of course, they might change their minds, or find someone else to do a deal with, who knows? We can always hope, at least. :-) >Microcontrollers (to me) are VLSI micros tuned in different directions >from more general-purpose micros. I'd happily hear a different term, >like microprocessor-tuned-for-embedded-systems, or whatever. How about embedded-processor? I've heard it used before. Or maybe embedded-CPU? // Randell Jesup Lunge Software Development // Dedicated Amiga Programmer 13 Frear Ave, Troy, NY 12180 \\// beowulf!lunge!jesup@steinmetz.UUCP (518) 272-2942 \/ (uunet!steinmetz!beowulf!lunge!jesup) BIX: rjesup (-: The Few, The Proud, The Architects of the RPM40 40MIPS CMOS Micro :-)