Path: utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!wuarchive!emory!stiatl!srchtec!johnb
From: johnb@srchtec.UUCP (John T. Baldwin)
Newsgroups: comp.realtime
Subject: Re: Software primitives for real-time programming languages
Keywords: Languages
Message-ID: <225@srchtec.UUCP>
Date: 24 Sep 90 15:43:48 GMT
References: <12712@cs.utexas.edu> <1424@umriscc.isc.umr.edu> <39180@shemp.CS.UCLA.EDU>
Organization: search technology, inc.
Lines: 37

In article <39180@shemp.CS.UCLA.EDU> frazier@oahu.cs.ucla.edu 
  (Greg Frazier) writes:

>In article <1424@umriscc.isc.umr.edu> rajuk@umree.isc.umr.edu 
> (Raju Khubchandani) writes:

>>I know this is a lot of programming effort compared to using
>>a high level language, but the objective is to extract maximum
>>juice from your hardware.

>
>No, this is not the goal.  The goal is to obtain reliable juice
                                                  ^^^^^^^^
>from your hardware, and assembly code is about the least reliable
>way to program a computer that I know of.

True.  The primary concern of real-time is to ensure that tasks reliably
*meet their time constraints*.  In the vernacular, we want "on time, at
the right time,"  not "as fast as we can get it."

I would argue that other forms of reliability are properly in the domain
of so-called "software engineering."  Thus I agree with the statement that
assembly coding is typically less "reliable" than other forms of coding;
yet I disagree that it is inappropriate for RT.  I would rather not
resort to assembler, but given certain task/hardware pairs, you only have
a certain time rate of execution ("performance"), and it may be that the
only way to meet the RT constraints of your given task on the specified
hardware is to use assembler.   :-{

Some of us might argue that the above is called "misspecification."  :-)


-- 
John T. Baldwin                      |  johnb%srchtec.uucp@mathcs.emory.edu
Search Technology, Inc.              | 
                                     | "... I had an infinite loop,
My opinions; not my employers'.      |  but it was only for a little while..."