[m-dev.] Adding standard integer types

[Julien Fischer]

On Thu, 18 Sep 2008, Ian MacLarty wrote:

> On Thu, Sep 18, 2008 at 5:33 AM, Julien Fischer
> <juliensf at csse.unimelb.edu.au> wrote:
>>
>> Hi,
>>
>> This actually a response to Pete's original post rather than to Paul's
>> comments since my spam filter decided that the former was spam and
>> deleted it.
>>
>> On Wed, 17 Sep 2008, Paul Bone wrote:
>>
>>> On Wed, Sep 17, 2008 at 02:07:50PM +1000, Peter Ross wrote:
>>>>
>>>> I'm looking at adding the type int8, int16, int32 and int64 to Mercury
>>>> and the equivalent unsigned versions.
>>>>
>>>> The way I'm currently imagining doing it is to add the following
>>>> module to the library.
>>>>
>>>> :- module stdint.
>>>> :- interface.
>>>> :- type int8.
>>>> :- foreign_type(c, int8, "int8_t").
>>
>> You will definitely want a can_pass_as_mercury_type attribute for int8,
>> int16 and int32.  int64 is a bit tricky, on 32-bit machines it will have
>> to be boxed but it should be unboxed on 64-bit machines.  I suggest
>> adding a new foreign type attribute:
>>
>>        unbox_bit_threshold(<Threshold>)
>>
>> that causes a foreign_type to be unboxed (passed as a Mercury type)
>> if sizeof(MR_Word) * 8 >= Threshold.

Incidentally, the above addition to foreign types will be useful in
other places as well.  I'll look at implementing it when I get back.
`cond_can_pass_as_mercury' would be a better attribute name than the
one I originally suggested.

>>
>>>> :- func to_int8(int) = int8.
>>>>
>>>> I will then add to the runtime the following portable stdint.h renamed
>>>> to mercury_pstdint.h
>>>>
>>>> http://www.azillionmonkeys.com/qed/pstdint.h
>>>>
>>>> and add to configure a test for stdint.h and if that doesn't exist we
>>>> would fall back to using mercury_pstdint.h.
>>>>
>>>> Does anyone have any objections/improvements to this plan?
>>
>> * How will all this be implemented for the other backends?  It should
>> be fairly trivial for the .NET and Java backends (although unsigned
>> integers don't exist in the latter.)  The Erlang backend?
>>
>> * It may be worth considering whether the new types should be implemented
>> as additional builtin types rather as a library module.
>>
>
> Doing them as builtins would play better with the mode system.  For
> example you could do something like:
>
> :- pred decode(uint8::in, code::out) is semidet.
>
> decode(1, code1).
> decode(2, code2).
> decode(3, code3).
>
> which wouldn't be possible if they were foreign types, (without first
> casting them to ints which might not be possible in the case of int64
> or uint64).
>
> Also you could read them in using io.read if they were builtins.

Here is a proposed extended set of integral builtin types for Mercury:

Type        Description 
----        -----------

int         word sized signed

uint        word sized unsigned

int8        8-bit signed
int16       16-bit signed
int32       32-bit signed 
int64       64-bit signed

uint8       8-bit unsigned 
uint16      16-bit unsigned 
uint32      32-bit unsigned 
uint64      64-bit unsigned

I have been intending to add uint as a new builtin for some time now.
(There are quite a lot of places in the runtime, debuger and deep
profiler where we use unsigned quantities in C code and then have to convert
them to signed values in Mercury which could be simplified by the
addition of uint.)

For uints, literals would be as they are for the signed versions
except that would have either `u' or`U' appended.  For the fixed size
types something like the following might be used:

 	42s8	- signed 8-bit integer with decimal value 42
 	42U64	- unsigned 64-bit integer with decimal value 42
 	42S32	- signed 32-bit integer with decimal value 42

> float32 and float64 would be nice too.

Yes, but one thing at a time.

Julien.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at csse.unimelb.edu.au
Administrative Queries: owner-mercury-developers at csse.unimelb.edu.au
Subscriptions:          mercury-developers-request at csse.unimelb.edu.au
--------------------------------------------------------------------------