cik@l.cc.purdue.edu (Herman Rubin) (03/06/88)
In article <25284@cca.CCA.COM>, g-rh@cca.CCA.COM (Richard Harter) writes: ........ > But how do I get stuff back. I can pass one thing back > via the return statement. To pass more than one thing I have to play > games. Things which are returned need a mechanism equivalent to pass > by address. No, what is needed is to abandon the mistaken notion that a function returns a single result. From day one, lists should have been allowed to the left of the replacement sign--this is not just for functions, but even for direct operators. For example, the infamous frexp function in C should not have the syntax y = frexp(x,&n); but y,n = frexp(x); This would, for example, allow n to be in a register, which is probably where it should be anyhow. Another example would be to have q,r = a///b; where the quotient and remainder are simultaneously produced. Possibly if that were in the language, we would not find the operation disappearing from hardware. ...... > > The following example is illustrative syntax only: > > [int *,int] foobar(); > .... > [ptr,flag] = foobar(arg) > int arg; > { > int *a, *b; > .... > return [a,1]; > .... > return [b,0]; > } I would drop the brackets, but otherwise the notation is reasonable. Another thing is to allow the return value to be stored _before_ the return statement. It may be desirable to do other computations after computing the value, especially for functions with side effects, such as random number procedures. -- 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
mrd@sun.soe.clarkson.edu (Michael R. DeCorte) (03/07/88)
Posting-Front-End: GNU Emacs 18.47.2 of Thu Dec 10 1987 on sun.mcs.clarkson.edu (berkeley-unix)
In article <700@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
No, what is needed is to abandon the mistaken notion that a function
returns a single result. From day one, lists should have been allowed
to the left of the replacement sign--this is not just for functions,
but even for direct operators. For example, the infamous frexp function
in C should not have the syntax
y = frexp(x,&n);
but
y,n = frexp(x);
Isetl has something of this sort. In Isetl [1,2,3] is a tuple and
if you say
[a,b] := [b,a];
you have a swap routine.
[a,b,c] := f();
and f() returns [1,2,3] you will get the assignments that you want.
Views expressed here do not represent Clarkson University or any part of it.
Michael DeCorte // (315)268-3704 // P.O. Box 652, Potsdam, NY 13676
Internet mrd@clutx.clarkson.edu // BIX DMichael
Bitnet mrd@clutx.bitnet // Compuserve 72220,3724ok@quintus.UUCP (Richard A. O'Keefe) (03/08/88)
In article <700@l.cc.purdue.edu>, cik@l.cc.purdue.edu (Herman Rubin) writes: > No, what is needed is to abandon the mistaken notion that a function > returns a single result. From day one, lists should have been allowed > to the left of the replacement sign--this is not just for functions, > but even for direct operators. MESA does this. Every function in MESA takes a record as argument and delivers a record as result. Since MESA has keyword constructors for records, this magically yields keyword inputs _and_ keyword results.
jbn@glacier.STANFORD.EDU (John B. Nagle) (03/09/88)
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.cik@l.cc.purdue.edu (Herman Rubin) (03/09/88)
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
twb@hoqax.UUCP (BEATTIE) (03/09/88)
I have been trying to ignore this D discussion but it seems to be going on forever. Why is this D discussion in the C group?
stuart@bms-at.UUCP (Stuart D. Gathman) (03/11/88)
In article <700@l.cc.purdue.edu>, cik@l.cc.purdue.edu (Herman Rubin) writes: > but even for direct operators. For example, the infamous frexp function > in C should not have the syntax > y = frexp(x,&n); > but > y,n = frexp(x); > This would, for example, allow n to be in a register, which is probably > where it should be anyhow. > Another example would be to have > q,r = a///b; > where the quotient and remainder are simultaneously produced. Possibly Another example is string comparison. I use a string compare function that returns the index of the first different character. I also need the gt/lt/eq result. Fortunately, in this case it is easily computed by recomparing the chars at the index. This is another case of a double valued hardware primitive. (Available on all three of the architectures we use: Series/1, 80286, 68020.) -- Stuart D. Gathman <stuart@bms-at.uucp> <..!{vrdxhq|daitc}!bms-at!stuart>
daniels@teklds.TEK.COM (Scott Daniels) (03/12/88)
In article <587@bms-at.UUCP> stuart@bms-at.UUCP (Stuart D. Gathman) writes: >Another example is string comparison. I use a string compare function >that returns the index of the first different character. I also >need the gt/lt/eq result. Fortunately, in this case it is easily >computed by recomparing the chars at the index. An alternative is the string comparison I normally use: cmpstr(s1,s2) 0: if equal >0: if s1 > s2 <0: if s1 < s2 abs(cmpstr(s1,s2)) is the number of chars compared: s1[ abs(cmpstr(s1,s2))-1 ] != s2[ abs(cmpstr(s1,s2))-1 ] if cmpstr did not return 0. Normally this function returns just about any information I need, and it is usually not very hard to make an extremely fast version in assembly. -Scott Daniels (daniels@teklds.TEK.COM)
aglew@ccvaxa.UUCP (03/13/88)
>I would not be so worried about the efficiency of passing values to and >from functions on non stack-based machines and be more worried about how >you are going to implement efficiently a language which allows recursion >(C, Pascal, etc.) on a non stack-based machine. Why should the 90% of all applications that are non-recursive (you can check it out at link time) pay for recursion?