[mercury-users] Tagged datatypes and boxing

[Ralph Becket]

I was very surprised when my compression program that *shouldn't* be doing
any structure creation turned out to be doing just that in spades.

A swift application of mprof later and it turns out that the culprits are a
couple of predicates in the inner loop that return tagged integers (there
are
only two possible tags in each case).  I had naively expected the compiler
to
steal a bit for this purpose, but of course that's unreasonable.  So the
compiler ended up boxing these things and, in the absence of compile-time
GC,
the program ends up putting all this stuff on the heap.

Typically I rarely require all 32 bits (or whatever) that I have in an int
and I'd like to be able to tell the compiler that it can use the rest for
tagging.  Call it a `short' or somesuch.  24 bits of payload should be
ample.

In fact, I have another suggestion.  Way back when in my systems days, it
was
a source of constant aggravation that the C standard didn't specify the
number
of bits/bytes occupied by the various integer types.  There are cases where
this sort of knowledge really matters.  I think I would like to see the
following types in Mercury: int8, int16, int24, int32, int64, and let plain
int be implementation dependent (e.g. 30 bits + 2 for tagging).  Use of the
intXX types would be subject to the standard mod 2^XX behaviour, while
the int library could specify upper and lower bounds and the number of bits
used as it does at present.

I'm aware that this would complicate the compiler somewhat, but I have a
funny
feeling that it would pay all sorts of dividends, not least in the
optimisation
department.

Cheers,

Ralph
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------