[comp.realtime] What is the future of realtime and RISC?

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
---   ---   ---   ---   ---   ---   ---   ---   ---   ---   ---   ---   ---