🚀 go-pugleaf

In article <1223@quintus.UUCP>, pds@quintus.UUCP (Peter Schachte) writes:
> In article <1989Jul17.184707.415@maths.nott.ac.uk> anw@maths.nott.ac.uk (Dr A. N. Walker) writes:

Only selected parts of the posting are commented.

>                        It does have the flaw that errcount can't be a
> register variable.  It is conceivable, though, that a global optimizer
> could put errcount into a register.

Any programmer understanding the machine may wish to force register.
I do not know of any machine/language combination for which this operation
can be done efficiently by providing an address.

> 	    The problem
> 	    is that usually, when you have multiple results, you want to
> 	    do different things with them.  In order to do that with
> 	    this sort of multiple values, you have to assign them to
> 	    separate variables.

Usually that is the case.  However, suppose you have a high-order iterative
solver, say using a function and its first four derivatives.  Now what is
usually done is to make 5 function calls to get those arguments.  But a
single call returning those 5 values is likely to cost far less than two
function calls returning one value.  So the 5-output result can be passed
to another subroutine intact.

But I agree.  What one should do is assign them to temporaries, which is
what a compiler does in evaluating a complicated expression.  Again, for
efficiency, these usually should not be stored and reloaded.

>	    Why
> 	    not just write functions that take pointers indicating where
> 	    to store the results, as I showed above?

Same remarks about registers as above.  In the case of evaluating expressions
not involving subroutine calls, the compiler or programmer usually assigns
the register locations.  It is definitely not the same as passing pointers.

> 	2.  The other approach is to treat multiple results as separate
> 	    things.  Forth, Pop-2, and CommonLisp do this.  Forth and
> 	    Pop-2 store results, as well as arguments, on a stack.  This
> 	    gives them great flexibility with multiple results; in
> 	    effect, multiple results are handled just like a single
> 	    result.  CommonLisp is a bit less flexible*.

It is neat, but agains stacks are expensive.  This may be a reasonable
way to do things for an expensive function call, but not for managing
hardware expressions.

> 
> It seems to me that the cleanest way to handle multiple results is to
> just always put them into variables.

I agree that this is a clean way.  But it is rarely an efficient way, just
as subroutine calls are rarely efficient ways of handling relatively short
procedures.  If we point some of these things out, we can get programmers
who will code efficiently with little effort.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)