cik@l.cc.purdue.edu.UUCP (01/01/87)
It is correct that most subroutine calls do a lot, and that subroutine salling is "absolutely" faster than it was many years ago. However, it is relatively far slower. Also, much of the time I do not want all of the junk that a subroutine call produces. -- (Usual disclaimer line.) Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 (decvax,ihnp4,uiucdcs)!pur-ee!stat-l!cik (decwrl,hplabs,ucbvax)!purdue!stat-l!cik hrubin@l.cc.purdue.edu
cik@l.cc.purdue.edu.UUCP (01/01/87)
It is true that the increased speed of hardware has made souroutine calls usually faster, but relatively much slower. On the CYBER 205, I estimate that a subroutine call will cost 50-100 instructions. It is also true that subroutine calls do a lot, but, especially in a program to be included in a library, do I want to call the fire department to extinguish a match? Even a transfer on many machines is now more expensive than most instructions. When the gurus first started touting HLL's, conditional transfers were cheaper that any arithmetic operations. Another problem with HLL's is that machine-trivial operations may be difficult to produce. Overflows, extractions, violating type restrictions, using condition codes on minis and micros, etc., are simple and efficient. The question of space saving has also been raised. It is true that usually a HLL source program is shorter than an assembler source program. However, this is mostly due to the horribly designed assembler syntax, and a well-designed assembler should not run over 1.5 times as much space as an equivalent HLL program, and may be very much shorter, since lengthy HLL constructions, such as structures, unions, and many declarations, can be omitted. The addition of macro capabilities can even do more. The object programs will almost always be shorter, and the space taken at run time even more so. An INLINE function may be shorter than the subroutine call; the C subroutine calls abs and fabs should always be inline, among many others. Another problem I have encountered, and the only satisfactory solution I have found is to modify the object file, is the inclusion of tables in a program. In several cases, the tables are computer generated, and there is no reason to read the tables in any way other than to verify their correctness. I have run into this problem many times, recently with 513 number tables. -- (Usual disclaimer line.) Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 (decvax,ihnp4,uiucdcs)!pur-ee!stat-l!cik (decwrl,hplabs,ucbvax)!purdue!stat-l!cik hrubin@l.cc.purdue.edu
rentsch@unc.UUCP (Tim Rentsch) (01/05/87)
In article <486@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: > It is correct that most subroutine calls do a lot, and that subroutine > salling is "absolutely" faster than it was many years ago. However, > it is relatively far slower. Also, much of the time I do not want all > of the junk that a subroutine call produces. The poster intends this as an argument in favor of assembly, as opposed to HLL's. Notice, however, that the observation (even if true) argues *against* assembly and in favor of HLL's. Reason: in assembly a call is a call, whereas in an HLL what is written as a procedure *need not* be compiled into a closed subroutine. In assembly, if you write CALLS (or whatever your favorite machines call instruction is), you get CALLS; in an HLL, if you write PROCEDURE (or whatever your favorite HLL's subroutine declaration keyword is), you *might or might not* get something called with a subroutine call instruction, on *any* machine. Upon reflection, I realized that the poster is arguing not against HLL's but against the practices of structured programming. I won't argue the virtues of structured programming here (although I happen to believe in them), but it seems worth pointing out that non-structured code (i.e., with no subroutine calls) can just as well be written in an HLL as in assembly language. This is not an argument against HLL's, even if (as the quoted poster seems to) you believe in non-structured code. If you DO believe in structured code, then the observation is in favor of HLL's (as the "reason" paragraph explains). Final point: "It is relatively far slower."?! Could you supply some facts which support this opinion? cheers, txr