Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-lcc!mordor!sri-spam!rutgers!mit-eddie!genrad!decvax!mcnc!unc!rentsch
From: rentsch@unc.UUCP (Tim Rentsch)
Newsgroups: comp.lang.misc
Subject: Re: Assembly language and Speed...
Message-ID: <464@unc.unc.UUCP>
Date: Tue, 23-Dec-86 23:03:40 EST
Article-I.D.: unc.464
Posted: Tue Dec 23 23:03:40 1986
Date-Received: Wed, 24-Dec-86 18:46:05 EST
References: <1233@navajo.STANFORD.EDU>
Reply-To: rentsch@unc.UUCP (Tim Rentsch)
Organization: CS Dept, U. of N. Carolina, Chapel Hill
Lines: 70

In some article William E. Westfield writes:
> It is true that any compiler can generate code as good or better than a
> human for straight line math code.  A good compiler ought to be able to
> optimize loops and array accesses and register allocation for complex
> expressions as well as a human.  But where HLL's fall down is when you
> start to do function and procedure calls.  And of course you should do
> a lot of those in a well structured program.

It seems to me that a well-structured programming style argues in
favor of a HLL, not against it.  The reason is that a provision for
"inline" procedure calls supports a highly procedurized style, while
not incurring the procedure call overhead (at runtime).  Contrast
with assembly where your write 'PUSHJ' (or whatever) to call a
subroutine.  Oh, I know all about macro assemblers, but macro
processors are never quite transparent, and then you have two
*different* mechanisms (with peculiar interactions).  With inlineable
procedures, on the other hand, there is uniformity of syntax,
identical semantics, strong type checking, all those other good
things, AND no procedure call overhead.  Just like having your cake
and eating it, too.  



> An assembly language programmer has the option of writing "fast"
> subroutines that pass arguments in registers and don't bother setting
> up stack frames, and so on.  He can make sure that the arguments he is
> passing in registers are already in the resgisters that they are
> supposed to be in, and results go where they are ready to be used next.
> Arguments can be passed by value or by reference, which ever is more
> convenient, or faster.  And of course there are special instructions to
> be exploited.

Again, inline procedures give a safer, easier to use mechanism, and
they run faster as well.  Argument passing?  Good compilers (some
actually exist) will check the body of the procedure and pass
parameters by renaming the variables in the procedure body, if the
renaming preserves the semantics of the procedure call.  The result
is that no data is moved (as in the assembler case), but without the
programmer having to think if the improved code will "work".  Here
is the crucial difference between HLL and assembler -- when I write
in assembler I have to think about each such optimization to be sure
it does the right thing.  Using inline procedure calls, the
semantics of the call is guaranteed not to change if the procedure
is made inline, so I never have to worry if passing an argument by
reference is identical to passing it by value -- the compiler does
that for me.

Exploiting special instructions is something most compilers do
poorly (if at all), so there should be an (infrequently used) escape
mechanism to generate them directly.  BUT, this escape should be
much more structured than the assembly language style of "anything
goes".  For example, the generated instructions should be
encapsulated within a procedure.  This way, the caller need not know
whether he is using the special instruction, and one implementation
can be exchanged for another completely transparently.  If combined
with the inline mechanism, the procedure call overhead again
disappears, and we obtain the best of both worlds.



Lest anyone think such a language is just a fantasy, I should say
that the MESA programming language supports both INLINE procedures
and procedures escaped to machine code.  If your view is that
therefore MESA is not an HLL but rather an assembler, well, I won't
disagree with you, but I will say in that case the the MESA
assembler is better than your assembler.

cheers,

txr