Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!ucsd!pacbell.com!tandem!netcom!mcmahan
From: mcmahan@netcom.UUCP (Dave Mc Mahan)
Newsgroups: comp.realtime
Subject: Re: Software primitives for real-time programming languages
Keywords: Languages
Message-ID: <14079@netcom.UUCP>
Date: 29 Sep 90 04:13:30 GMT
References: <39180@shemp.CS.UCLA.EDU> <225@srchtec.UUCP> <5003@uqcspe.cs.uq.oz.au>
Organization: Dave McMahan @ NetCom Services
Lines: 53


 In a previous article, brendan@batserver.cs.uq.oz.au writes:
>johnb@srchtec.UUCP (John T. Baldwin) writes:
>>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.   :-{
>
>	Probably the compiler writer knows more about extracting "juice"
>	out of the processor than most programmers, but I will ignore
>	that fact.

I have found that they guy may know more about getting maximum juice, but it
doesn't always appear in the produced code.  The compiler I recently purchased
was touted as being faster than all the competition and better than I could
code myself in assembly language.  Yet, I find that it does really dumb things
when doing very simple operations.  It is highly biased toward using registers
(a selling point) but will use them even when a straight coding of :
   move MemA,MemB

would be much faster.  In general, I have found that compilers are very good
at doing some things, but seem to be brain dead at doing other (seemingly)
simple things.  The overall benefits from using one far outweigh the downside,
however.


>	Ian Hayes has just walked in and suggested that a language in which
>	you could make timing demands on the compiled code would be
>	useful. For example
>		a := exp | /\ t < 4 microsecs;
>	Inability to comply would be flagged as a "syntax" error, along
>	the lines of type mismatches etc.

I like this idea, but I'm not sure how easy it could be to implement.  How can
the compiler know about caches, memory wait states, CPU clock cycles, etc?
It would be an excellent way to produce verifiable code, but it would have
to be able to determine such analysis from data that is not available at
compilation time.  Would it be much better to create a tool that would provide
a formula for execution of a routine?  This might appear as:

foobar.c:                2                   3 
          a(input1_count)   - b(input2_count) + c

where a, b, and c are defined in CPU cycles and input1_count is the maximum
size of of input1 or the biggest count of elements in input1, or whatever.
This would still provide only a guess in a CPU that includes cache, pipelines,
etc.


>Brendan Mahony                   | brendan@batserver.cs.uq.oz       

  -dave