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