Xref: utzoo comp.lang.c:7944 comp.lang.misc:1173
Path: utzoo!mnetor!uunet!husc6!mit-eddie!bbn!rochester!udel!gatech!purdue!i.cc.purdue.edu!k.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.lang.c,comp.lang.misc
Subject: Re: The D Programming Language
Message-ID: <704@l.cc.purdue.edu>
Date: 9 Mar 88 13:06:40 GMT
References: <25284@cca.CCA.COM> <700@l.cc.purdue.edu> <505@sun.soe.clarkson.edu> <17351@glacier.STANFORD.EDU>
Organization: Purdue University Statistics Department
Lines: 38
Summary: This is not as efficient as it looks.

In article <17351@glacier.STANFORD.EDU>, jbn@glacier.STANFORD.EDU (John B. Nagle) writes:
> 
>     If you want multiple values from functions, look at Mesa, which offers
> an efficient approach.  In Mesa, all functions effectively take one argument
> and return one result, but both are structures.  The normal function call
> syntax is treated as a structure constructor which builds a structure out
> of the arguments, then passes the structure as a unit.  The structure is usually
> built on the stack, and thus this is equivalent in an implementation sense
> to the passing of parameters on the stack.  In turn, a function returns a
> result which is a structure.  The space for that structure is allocated by
> the caller, on the stack, and its address is passed to the function, which
> then fills it in.
> 
>     This approach seems to work.

There are two problems with this.  While using stacks may be easy to program,
it involves lots of loads and stores.  I know of at least one machine on which
the normal subroutine call and return do not use stacks.  Furthermore, if the
called routine may make additional calls, it may be necessary to use a 
separate return stack, and this may require each such subroutine to maintain
its own return stack.  In some cases this should be the way to do things,
but not always.

Another problem comes with inline functions.  I believe that many function
calls, if not most, should be inline.  In this case, I think the result should
go to its destination at the time produced.  If the destinations involve
registers or register indirects, the expression of the algorithm must take
the busy set of registers into account.  This admittedly makes coding 
difficult, and is one reason why I believe DNA can optimize better than
silicon.  (The two should be used together, but I do not know of any compiler
which allows the programmer to even give it a hint as to how to optimize,
let alone improve the resulting product.)


-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (ARPA or UUCP) or hrubin@purccvm.bitnet