Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!aplcen!haven!decuac!shlump.nac.dec.com!alien.enet.dec.com!mcculley
From: mcculley@alien.enet.dec.com
Newsgroups: comp.realtime
Subject: Re: Software primitives for real-time programming languages
Message-ID: <15783@shlump.nac.dec.com>
Date: 4 Oct 90 00:50:32 GMT
Sender: newsdaemon@shlump.nac.dec.com
Organization: Digital Equipment Corporation
Lines: 60


In article <1851@tuvie>, alex@vmars.tuwien.ac.at (Alexander Vrchoticky) writes...
>rajuk@umree.isc.umr.edu (Raju Khubchandani) writes:
>>I have read more than I have hands-on experience with programming languages,
>>but would anybody disagree that the fastest way to execute is 
>>using the assembly level language of any processor? 
> 
>How could anyone ? :-)

For sure it's the fastest way to execute instructions, the problem statement is
insufficiently defined to determine whether or not it's the fastest way to
execute code.

>>level programming. 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.
>The objective is to produce software that is reliable, maintainable,
>readable and meeting its timing connstraints. Note that
>`extracting maximum juice' is not a timing constraint. 

No.  The objective is to meet requirements.  Requirements define the priority
assigned to all those other objectives.

If you have hardware that (for whatever reason) can't be changed and it's
running out of grunt, you may need to extract maximum juice at the expense of
maintainability in order to meet the timing constraints.  That's all part of
the real world requirements definition (something all too often missing in the
academic abstractions studied as science).

As far as the base question goes, you just can't say.  Some other replies to
this thread stated some assumptions to the effect that the compiler writer
probably knew as much or more about getting maximum juice out of the
environment, but that's just as unfounded as the opposite assumption.  Truth
is, a good compiler will outperform a bad compiler, and a good assembly
programmer will outperform a bad assembly programmer.  Just how any given
compiler and BAL programmer stack up vis a vis one another depends on their
relative merits.  In theory, the best a good compiler should be able to do is
to match a good assembly programmer (after all, if he's good enough he'll just
write the same code as the compiler outputs, right?).  In the real world, I
doubt any compilers do that well, and I doubt many programmers do either.

I work in assembler, all the time.  In an environment I've used for that for
over ten years now.  I'll match my skills against any compiler around, in that
sandbox, for the job I do.  I won't argue the issue for any other conditions
though.

My own belief is that assembler and compiler languages are different tools,
like all tools different jobs are more or less well suited to each of them.

In other words, don't think nails and screws are meant to do the same job.

(HINT: if you think nails and screws are completely interchangable, consider
tension loading.)

Bruce McCulley		; heck, I don't know the mail path, look at the header
Central Engineering
Digital Equipment Corp.
Nashua, NH