Re: Multiple return values

fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:


      I suppose the approach that Pieter Schoenmakers described is a
      compromise; in his language "Tom", tuples are not first-class types,
      and so it would probably be easy for a compiler to return tuples of
      results in registers. But I think I'd prefer tuples to be first-class
      types.


A next version of TOM will probably have expanded classes. A tuple
type will then be an anonymous expanded class with no methods apart
from the trivial accessors; a tuple will be an initializer for a tuple
typed value. All very static (as in `compile time'; contrary to TOM
doing almost everything dynamic), but that's what you get, and want,
with expanded classes.


As far as the compiler is concerned, with a uniform procedure call
mechanism for every, eh, `procedure', you can do as much with tuples
as GNU CC does with structures: pass them like normal arguments (part
register, part stack) and return them in registers if they're small
enough, or on the stack if they're large. This makes me wonder: why
aren't they split between registers and the stack when returned?
Especially when the values returned (and packed into a struct) are
seperate, distinct values as opposed to a single struct value, this
would be a speedup, since the first odd returned values would not need
to be stored in the stack and loaded into a register again when needed
after the return. I guess it isn't worth the trouble because this
usage does not fit C programming style. In fact, the current TOM
compiler uses the same mechanism as any C programmer: the first value
is the return value of the C function (TOM uses C as the output
language); the other values are returned through `out argument'
pointers.
--Tiggr
--
The advantage of using an unknown programming language is that you
don't have to answer questions on how it compares to Java.
http://tom.ics.ele.tue.nl:8080


--

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