[m-dev.] for review: passing boxed floats to pragma C code

[Fergus Henderson]

On 28-Dec-1999, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> 
> Add support for passing boxed float arguments to pragma C codes, i.e. as Words.
> This requires the C code to call word_to_float on inputs and float_to_word
> on outputs as necessary, but also allows C code to store *already boxed*
> floats in data structures, and return them to C code without the memory
> allocation inherent in reboxing.
...
> compiler/prog_data.m:
> 	Add an extra kind of attribute to pragma_c_code goals: the
> 	pragma_float_format, with two values: pragma_unboxed_float and
> 	pragma_boxed_float. With the former, which is the default, float
> 	arguments are passed to and from pragma C code as type Float, as now.
> 	With the latter, they are passed in boxed form, as type Word.

You can already achieve that, by declaring the C code
to have a polymorphic type.  Instead of

	:- func foo(float) = float.
	:- pragma c_code(foo(X::in) = (Y::out), pragma_boxed_float, ...).
	
you can write

	:- func foo(float) = float.
	foo(X) = foo_boxed(X).

	:- func foo_boxed(Float1) = Float2.
	:- pragma c_code(foo_boxed(X::in) = (Y::out) is det,
		% The C code below assumes Float1 = Float2 = float.
		% This is OK because foo_boxed/1 is called only from foo/1.
		...
	).

Given that this feature is easy to simulate in this manner,
and that the need for it is rare (after all, the word_to_float()
and float_to_word() macros are not part of the documented interface,
so they can only be used within the Mercury implementation),
I'm not convinced that it would be worth complicating the C code
interface with this feature.

> When this change has been bootstrapped,
> I will modify the routines in mercury_tabling.c and private_builtin.m
> that save and restore floats to use this new facility.

Is that case really worth optimizing?
It seems to me that tabling of floats would probably be fairly rare.

For the MLDS back-end, we pass float arguments unboxed.
So in many cases, this would not gain anything.

For the LLDS back-end, our long-term plan was also to eventually
pass float arguments unboxed, in separate floating point registers.
That now appears unlikely, since in the long term we will probably
shift our focus from the LLDS back-end to the MLDS back-end.
However, if floats were passed in float registers, then this
planned optimization in mercury_tabling.c and private_builtin.m
would in many cases not gain anything for the LLDS back-end either.

I think it would probably be better to worry about correctness
(e.g. getting tabling to work for nondet code) before worrying
about optimizations for rare cases.

> compiler/code_gen.m:
> 	In code_gen.m,
> 	also fix a bug: the may_call_mercury attribute was being ignored.

This change should of course go ahead.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- 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
--------------------------------------------------------------------------