Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!umd5!purdue!i.cc.purdue.edu!j.cc.purdue.edu!pur-ee!uiucdcs!uxc.cso.uiuc.edu!urbsdc!aglew
From: aglew@urbsdc.Urbana.Gould.COM
Newsgroups: comp.arch
Subject: Re: RISC != real-time control
Message-ID: <28200135@urbsdc>
Date: 26 Apr 88 15:43:00 GMT
References: <1521@pt.cs.cmu.edu>
Lines: 25
Nf-ID: #R:pt.cs.cmu.edu:1521:urbsdc:28200135:000:1020
Nf-From: urbsdc.Urbana.Gould.COM!aglew    Apr 26 10:43:00 1988


>So, what is a real-time control designer to do?
>
>-- De-rate the RISC MIPS ratings to assume 100% cache misses?

You have to do this for CISCs with caches, not just RISCs.

>-- Use (probably) non-existent tools to compute worst-case
>   program execution time under all possible conditions?

In a hard real time environment you have to do thisd for CISCs
as well as RISCs. I don't know of any tools to do this *well*
in either camp, but building them should be considerably easier
for a RISC than a CISC, given the preponderance of short,
single cycle instructions, and explicitness of timing constraints.
On a CISC you never know what interlock is going to bite you.
    In fact, wasn't this one of the original reasons for RISC -
simple instructions make performance of code sequences easier
to calculate, and hence easier to choose between in optimization?

>-- Not use RISC in an environment with short deadline events?

I rather think that the GE RPM-40 guys will disagree with you about
that...

aglew@gould.com