scott@nbc1.ge.com (Scott Barman) (05/16/91)
I have been looking into realtime for automation projects here and learning a lot about the industry and what realtime really is. But like everything else, once the box is open the questions follow. Before I can even think about recomemending a system to use here I need to consider the realtime world and RISC processors. All the realtime software vendors I've spoken with tell me that the Motorola 680x0 architecture is still the dominant one used in the realtime world. But some admit to seeing an increase in requirements for RISC processors. The AMD 29K and Intel i860 and i960 seem to be making some inroads, but most say 85% of their business is Motorola CISC-based. There is some promise of SPARC and the 88K is not getting a lot of play. So I want to open up the discussion for net.land: + What is the future of realtime and RISC? + With the rise of RISC over the last few years why hasn't it taken a hold in the realtime world? + Is there going to be a market for SPARC with all the Suns out there to do cross-development work on eventhough there are really only two manufacturers making boards with SPARC processors (Force and Ironics)? + I wish I knew more about the new Intel chips. I've heard some good and bad things about them. Are they worth a look for a system? + What is it about the Motorola 88K that realtime software vendors seem to almost treat it as something insignificant? + The 29K has almost a religious following among its users. Why? It seems that AMD has done a good job in positioning this processor (almost like Sun and SPARC), is that significant? + And what about the future of the 68K? How long can it keep its domination in the realtime world? I see RISC chips turning up in some interesting areas (the new SGI machines, for example), is this going to make in-roads into this very established market? OK, I've presented only a part of the questions I have. Let's open up the discussion and see what happens! Thanks! -- scott barman | "Damn straight it worked!" scott@nbc1.ge.com | -- Mets manager Bud Harrelson commenting (This does not represent any | on the Opening Day steal of home. opinions of NBC or affiliates) | Let's Go Mets!! (Darryl who?)
georg@sgl (Georg Feil) (05/17/91)
scott@nbc1.ge.com (Scott Barman) writes: >+ With the rise of RISC over the last few years why hasn't it taken a >hold in the realtime world? Some reasons I can think of (feel free to argue): -Real-time systems are often required to be extremely reliable, as failures can mean expensive equipment damage (process control) or even loss of life (critical aircraft and spacecraft systems). Therefore implementors are simply more cautious about following the latest trend of doing things. They know their old methods work. NASA and the US space program are a good example: they were flying core memory around long after the rest of the world had moved on to semiconductors. -For those who do real-time programming in assembler, working with a RISC processor is probably more painful. -RISC cross-compilers are not quite as numerous as those for 680x0. -Fewer real-time kernels are available. I assume this is due to the work involved in porting them. It is my impression real-time kernels are traditionally coded in assembler, although this is probably an incorrect assumption these days. -RISC code sizes are greater than CISC, impacting those with limited EPROM or RAM space requirements. -RISC can have longer context-switch times with more registers to save. -With RISC fanciness such as delayed branches and greater reliance on caching, the hard determinism required in many real-time applications is more difficult to come by. >+ What is the future of realtime and RISC? Probably the same as the future of RISC in general, only delayed by a number of years. However, this applies mainly to "high-power" real-time applications. Those small embedded systems which don't need additional CPU speed will see no reason to switch to RISC. Witness the large number of 8051's out there and still being designed into new systems. The 8-bit microcontroller market is the largest of any class, and is likely to remain that way. For the same reasons, we'll be seeing 680x0's for a long time to come. Georg. -- Georg Feil Internet: georg@sgl.ists.ca Space Geodynamics Laboratory (toronto.edu address no longer valid) ISTS, 2700 Steeles Ave West Phone: (416) 665-5458 Toronto, Ontario Fax: (416) 660-1422
gillies@m.cs.uiuc.edu (Don Gillies) (05/18/91)
georg@sgl (Georg Feil) writes: >-With RISC fanciness such as delayed branches and greater reliance on > caching, the hard determinism required in many real-time applications > is more difficult to come by. I disagree with this. RISC processors are much more deterministic than previous-generation CISC processors. Nearly all instructions in RISC architectures such as MIPS have a latency of 5 cycles and take exactly 1 cycle to execute. The latency of delayed branches is completely predictable. Memory fetches must be (somewhat) aligned, so that loads takes exactly two cycles to execute. I fail to see how RISC machines rely more on cacheing than CISC machines. Give me a RISC and a CISC with identical memory systems and identical SPECmark, and I think you'll find the caching is greater on the CISC. On the other hand, machines line the modes 68020 are highly unsuitable for real-time systems, because the performance gap between best-case and worst-case performance can often be a factor of 3-4, even for straight-line code. When you have a 3-4 times performance hit in the worst case, you might as well use a 68000. Don Gillies | University of Illinois at Urbana-Champaign gillies@cs.uiuc.edu | Digital Computer Lab, 1304 W. Springfield, Urbana IL ---------------------+------------------------------------------------------ "WAR! UGH! ... What is it GOOD FOR? ABSOLUTELY NOTHING!" - the song "WAR" by Edwin Starr, circa 1971 --
mcgregr@bcars434.uucp (Andrew McGregor) (05/18/91)
In article <1991May17.170601.26095@m.cs.uiuc.edu> gillies@m.cs.uiuc.edu (Don Gillies) writes: > >georg@sgl (Georg Feil) writes: > >>-With RISC fanciness such as delayed branches and greater reliance on >> caching, the hard determinism required in many real-time applications >> is more difficult to come by. > >I disagree with this. RISC processors are much more deterministic >than previous-generation CISC processors. Nearly all instructions in In the case of the 80960 some of our people had an interesting experience. Some measurements on finished code indicated that interrupts were taking 2-3 times longer than spec. Much hairy analysis later they realized that the idle loop of the software tended to queue several memory accesses into a slow area of RAM so that when the interrupt hit and the state had to change the interrupt was delayed until all outstanding memory accesses had completed. I'm inclined to agree with the first poster that a RISC chip will tend to be hairier, mostly because of what they do with all the extra real estate (superscalar stuff, register windows, etc...) Andrew McGregor (MCGREGR@BNR.CA) Phone: (613) 763-7236 Bell-Northern Research P.O. Box 3511, Station C, Ottawa, Ontario, Canada, K1Y 4H7 -- Andrew McGregor (MCGREGR@BNR.CA) Phone: (613) 763-7236 Bell-Northern Research P.O. Box 3511, Station C, Ottawa, Ontario, Canada, K1Y 4H7
greg@organia.sce.carleton.ca (Greg Franks) (05/23/91)
In article <1991May15.210430.1134@nbc1.ge.com> scott@nbc1.ge.com (Scott Barman) writes:
I have been looking into realtime for automation projects here and
learning a lot about the industry and what realtime really is. But like
everything else, once the box is open the questions follow. Before I
can even think about recomemending a system to use here I need to
consider the realtime world and RISC processors.
All the realtime software vendors I've spoken with tell me that the
Motorola 680x0 architecture is still the dominant one used in the
realtime world. But some admit to seeing an increase in requirements
for RISC processors. The AMD 29K and Intel i860 and i960 seem to be
making some inroads, but most say 85% of their business is Motorola
CISC-based. There is some promise of SPARC and the 88K is not getting a
lot of play.
OK, I've presented only a part of the questions I have. Let's open up
the discussion and see what happens!
I think one important factor is cost. RISC chips are still rather
pricy, whereas 68000's are practically a commodity item these days.
Real time systems use *REAL* memory, so they don't need fancy memory
systems. Virtual memory is virtually unheard of (and usually
undesired because of the headaches of swapping pages in and out and
the effects of latency that paging causes). Furthermore, fewer chips
in the memory subsystem means less real estate and lower costs. I
believe that 29000's are pretty friendly when it comes to el-cheapo
memory design, whereas I don't think that can be said about 88000s.
This factor may explain the 29000's popularity.
Finally, real time systems tend to have a lot of light weight
processes that communicate with one and another; the processes do not
spend lots of CPU time crunching numbers. Chips that can switch state
quickly will be at an advantage.
--
Greg Franks, (613) 788-5726 | "The reason that God was able to
Systems Engineering, Carleton University, | create the world in seven days is
Ottawa, Ontario, Canada K1S 5B6. | that he didn't have to worry about
greg@sce.carleton.ca ...!cunews!sce!greg | the installed base" -- Enzo Torresi
csg@pyramid.pyramid.com (Carl S. Gutekunst) (05/30/91)
>All the realtime software vendors I've spoken with tell me that the >Motorola 680x0 architecture is still the dominant one used in the >realtime world. Actually, no. The dominant architecture in realtime and embedded systems is the Intel MCS-48 family, including the 8051. That should tell you a lot of the reason why you don't see more RISC chips. Realtime is very conservative, and very cost sensitive: you don't use a processor that costs any more than you have to. Pyramid is still doing all kinds of imbedded stuff with the 68000 -- despite our main systems using the MIPS R3000 -- because the 68000 does every- thing we need it to do. Only for some new specialized stuff are we going to faster processors, where we can prove customers need that performance. Note that 99.9999% of the CISC vs. RISC issues are academic blither, of no consequence to the developer. The valid questions are: how fast does it go? What are the memory bandwidth requirements? Real estate, and glue chips? Can I predict latencies? And by far the most important of all: how much does it cost? You'll get answers all over the map, for both RISC and CISC. <csg>
fred@mot.COM (Fred Brunner) (06/08/91)
In article <1991May15.210430.1134@nbc1.ge.com>, scott@nbc1.ge.com (Scott Barman) writes: |> I have been looking into realtime for automation projects here and |> learning a lot about the industry and what realtime really is. But like |> everything else, once the box is open the questions follow. Before I |> can even think about recomemending a system to use here I need to |> consider the realtime world and RISC processors. [...] Just a quick observation, esp. wrt the comment about the 88K. EE Times ran a cover story this week indicating that Motorola had been selected by Ford to be the embedded controller of choice for the late 90's, using- the 88K. Actually, something called the 88300 family, presumably similar in integrated functionality to the 68300 CISC family. The party line from the beginning with this family was that it would be a broad family of parts, able to be tailored to a wide range of applications, since the design was compiled/modular, etc. Perhaps some of this is beginning to bear fruit. -- --- --- --- --- --- --- --- --- --- --- --- --- --- Fred Brunner - Sr. Systems Engineer Intelligent Vehicle/Highway Systems Group - Motorola, Inc. >email<: fred@mot.com >voice<: (708) 205-2871 >fax<: (708) 205-2890 >USnail<: Motorola,Inc. 4000 Commercial Ave. M/S: IL08 Northbrook IL 60062 --- --- --- --- --- --- --- --- --- --- --- --- ---