Re: Multiple return values

Henry Baker wrote:
>
> From an implementation point of view, there are two critical properties
> of the multiple value that is just 'an ordered pair' (or tuple):
> * it is a _read-only_ pair (or tuple), which means that you don't have to
> supply it with an 'object identity' (address/pointer); and
> * it is received by exactly one receiver and then discarded (linear/unique
> property)
> Knowing these two properties allows for an extraordinarily efficient
> implementation of multiple return values. If you try to emulate
> multiple return values using 'heavier' objects --- those with object
> identity and reference counts >1 --- then prepare yourself for a very
> slow implementation.


Yes, this conversation often comes up on comp.lang.scheme. The
upcoming R5RS scheme language standard ("Real Soon Now! Honest!")
specifies multiple-result function returns and multi-argument
continuations.


As an implementor, I've been trying to dream up a "nice" and efficient
way to handle multiple returns from functions, and I'd like to hear
more about the method whose existence you mention above.


As far as I've gotten in thinking about it is to try to detect whether
the calling code wants (will actually use) one return value or more
(most of the time I figure it'll only want one) and compile separate
versions of the function; one which returns a single value (in
registers or on the stack) and one which returns more than a single
value (likewise).


That's been my standard approach to several optimization problems; I
have an intermediate form whose types closely match scheme's, and then
where the actual representations differ (such as between pointers at
bignums vs. immediate integer values), I compile separate versions of
the function calls. I then use type inference in the calling code to
link to the proper chunk o' machine code, which is sometimes explicit
type-checks and dispatching and sometimes just the raw compiled
functions themselves. This leads to a fair amount of code duplication
but minimizes runtime type checking. It sucks up memory, but it
executes with blazing speed.


Anyway, that will avoid using a "heavy" object to return function
results, but it will *further* bloat the compiled executable, and your
communication seems to indicate another approach. Perhaps I'm being
dense, but I don't see it -- can you say a little more?


Bear
--

Return to the comp.compilers page.
Search the comp.compilers archives again.