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

[Peter Schachte]

On Wed, Dec 08, 1999 at 02:32:49AM +1100, Fergus Henderson wrote:
> > > I need to introduce some new options and grades for the MLDS back-end.
> 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'.

If they're pretty well hidden away so users don't accidentally trip
over them, that's fine.

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

You've haven't mentioned the most important reason: it allows more
flexibility in term representation.  Eg, we discussed on this list the
idea of packing terms so that they take fewer words to represent than
the number of arguments.  When you can squeeze a compound term into a
single word, you can avoid boxing it, and that would be a big time and
space win.  Also, --high-level-data would give the possibility of
treating some C structures as ordinary Mercury terms.  This would be a
big convenience.  All in all, I would expect --high-level-data to be
pretty much all gain and no loss, and so should just replace the
current scheme.

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

I would assume you'd still want to use the low bits of a term pointer
as a sort of tag.  I can't see how you can get acceptable efficiency
for types with more than one non-niladic functor without that.  Lists
would be ok, but 2-3-4 trees would be hurt.


-- 
Peter Schachte                     Lisa, if you don't like your job you
mailto:schachte at cs.mu.OZ.AU        don't strike. You just go in every day
http://www.cs.mu.oz.au/~schachte/  and do it really half-assed. That's the
PGP: finger schachte at 128.250.37.3  American way. -- Homer Simpson 
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------