[m-dev.] grades for MLDS back-end

[Fergus Henderson]

On 07-Dec-1999, Peter Schachte <schachte at cs.mu.OZ.AU> wrote:
> On Mon, Dec 06, 1999 at 07:47:21PM +1100, Fergus Henderson wrote:
> > I need to introduce some new options and grades for the MLDS back-end.
> > 
> > 	grade		options
> > 	-----		-------
> > 	hl		--high-level-code --high-level-data
> > 	hlc		--high-level-code
> > 	hl_nest		--high-level-code --gcc-nested-functions
> > 	hlc_nest	--high-level-code --high-level-data --gcc-nested-functions
> 
> Presumably these need to be combined with a choice of garbage
> collector (or none), trailing or not, and various debugging options.

Right.  Also there's a few different variants of profiling to consider too.

Currently the MLDS back-end doesn't support any of those yet.
Currently it requires the conservative garbage collector,
and trailing and debugging are not yet implemented.
But probably that will change eventually.

> That makes for a *lot* of grades.  A full installation of each library
> file in each mmc-supportted grade is starting to get pretty big.  Can
> you explain why these are worth that complication?

All of these options affect link compatibility, so if we
are to support these options at all, they must be new grades.

But not all of these would be installed by default.
Indeed not all of these would be installed even if you
configure with `--enable-all-grades'.
So they wouldn't all be "first class" grades in that sense.
In fact I would expect only one of them (either hl or hlc)
to become a "first class" grade.

> In particular,
> what does --high-level-data mean and why not just always use it?

--high-level-data will mean using C types such as structs
rather than treating compound terms as arrays of words indexed
via the `MR_field()' macro.

One reason to implement these options is that of academic interest:
I want to be able to benchmark various combinations of these options,
so that we can get a good idea of the affect each one has on performance
(and so that I can include the benchmarking results in a paper).

Another reason is that --high-level-data will require a lot of work to
implement (quite a bit of the code generation and a lot of the RTTI
support will need major changes to handle it) and I would like to
bootstrap and test one major change at a time.

Also, depending on how we handle discriminated union types,
--high-level-data may end up less efficient.

> Also, your description of nested functions doesn't make it sound
> terribly useful; why is it worth the introduction of yet more grades?

`--gcc-nested-functions' is probably mostly only of academic interest,
for benchmarking.  But it also makes the generated code easier to read,
and may make debugging with gdb easier, so it could be useful for other
purposes as well.

Actually now that I think about it a bit more, I've realized that it would be
possible to implement `--gcc-nested-functions' in a way that didn't affect
the calling convention, at the cost of passing an unnecessary extra
parameter in the case when `--gcc-nested-functions' was enabled. 
That is probably a price worth paying.

-- 
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
--------------------------------------------------------------------------