[m-dev.] introduce box/unbox float operators in HLDS

[Fergus Henderson]

On 14-Mar-2001, Peter Ross <peter.ross at miscrit.be> wrote:
> The following code
> 
> scale_x(S, p(X, Y)) = p(S*X, Y).
> 
> is represented in the HLDS by
> 
> scale(S, P0) = P :-
>     PO => p(X, Y),
>     NewX := S * X,
>     P <= p(NewX, Y).
> 
> I would argue that we should represent it as the following in the HLDS,
> thus allowing structure reuse to see the box/unboxing, and reuse the
> cells where possible.  Of course when floats are unboxed then we revert
> back to the original HLDS representation.
> 
> scale(S, P0) = P :-
>     P0 => p(BoxedX, BoxedY),
>     BoxedX => box(X),
>     BoxedY => box(Y),
>     NewX := S * X,
>     NewBoxedX <= box(NewX),         % Reuse the BoxedX cell>
>     NewBoxedY <= box(Y),            % Reuse the BoxedY cell.
>     P <= p(NewBoxedX, NewBoxedY).   % Reuse the P0 cell.
>
> What are the problems with this suggestion?  

That's not a bad idea, but it would be a lot of work.

Currently the decision as to if and when to box things is left
up to the back-end, and the different back-ends do it differently;
the LLDS back-end boxes all procedure arguments, whereas the
MLDS back-end only boxes polymorphic procedure arguments
(currently both back-ends box all fields, though).

Making boxing explicit in the HLDS would therefore make
the HLDS back-end specific.  If this is done, it should
preferably only be done after semantic analysis, towards
the end of the HLDS->HLDS transformations.


What types do you use for boxed and unboxed floats?

If you use the same type, then parts of the compiler which expect
things that have the same type to have the same representation
will be confused.  That approach is not a good idea.

If you use a different type, then there are some additional complications. 
When you transform the HLDS to make boxing explicit, you'd need to change
the types, otherwise the HLDS would remain type-correct.
If you introduce a new `unboxed_float' type, then for the MLDS
back-end, you'd need to change the parameter types for procedures
withing floating point parameters from `float' to `unboxed_float'.
But then to keep higher-order code type-correct, if the address of such
a procedure is taken (i.e. you form a closure from that procedure)
you can't use it directly; instead, you need to introduce wrapper
procedures whose parameters have type `float' which do the appropriate
unboxing of input parameters, call the versions with `unboxed_float'
parameters, and then box the output parameters.

The MLDS back-end already has code to handle that, of course.
But you'd need to do it during the HLDS->HLDS transformation,
instead of doing it during the HLDS->MLDS code generation.
In fact splitting out the code for handling boxing/unboxing
into a separate pass would be good for maintainability of the code;
code generation tends to be complicated enough already, so in general,
the less things that are done during code generation, the better.
So I think this would be a good thing in the long run.
However, I think it would be a lot of work, and I'm not sure
if it's worth the effort right now.  There are probably lots of
other things which are more important.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------