[m-rev.] for review: add builtin 8, 16 and 32 bit integer types -- Part 2

[Julien Fischer]

On Mon, 21 Aug 2017, Zoltan Somogyi wrote:

>
>
> On Mon, 21 Aug 2017 01:03:35 +1000 (AEST), Julien Fischer <jfischer at opturion.com> wrote:
>>> If the current state of bootstrapping allows you to replace each cast_from_int(0)
>>> with 0i8, 0u8 etc, then please do so, since that would make all the returned values
>>> compile time constants.
>>
>> This is the change that allows the compile to recognise 0i8 etc. so that's
>> not possible.  I will replace the calls to cast_from_int above and elsewhere
>> once this has bootstrapped.
>
> So everyone: install the compiler soon after Julien commits this change.
>
>>>> +to_int8(Integer, Int8) :-
>>>> +    Integer = i(_Sign, [Digit]),
>>>> +    int8.from_int(Digit, Int8).
>>>
>>> The extremely scant documentation in integer.m on the meaning of the representation
>>> it uses makes me unable to determine whether ignoring _Sign here is a bug or not.
>>> Someone else who does know this representation should review the changes to integer.m.
>>
>> It's not a bug; the the digits are also signed.
>
> Then what is the _Sign for?

Despite the name it's actually the sign of the integer *and* length of
the digits list.  (integer.m is not terribly consistent about the name.)

> Can you please document the meaning of integer.m's representation?

Shall do.

>>>> +put_int8(Stream, Int8, !State) :-
>>>> +    ( if
>>>> +        % Handle the common I/O case more efficiently.
>>>> +        dynamic_cast(!.State, IOState0),
>>>> +        dynamic_cast(Stream, IOStream)
>>>> +    then
>>>> +        io.write_int8(IOStream, Int8, unsafe_promise_unique(IOState0), IOState),
>>>> +        ( if dynamic_cast(IOState, !:State) then
>>>> +            !:State = unsafe_promise_unique(!.State)
>>>> +        else
>>>> +            error("stream.string_writer.put_int8: unexpected type error")
>>>> +        )
>>>> +    else
>>>> +        put(Stream, string.int8_to_string(Int8), !State)
>>>> +    ).
>>>
>>> Does this code really handle the I/O case more efficiently than just using the else case
>>> for everything? It seems to have a significant amount of overhead, though I suppose it is
>>> a constant amount of overhead, while the latter has overhead proportional to the length
>>> of the string printed.
>>
>> Simon added the above pattern for the builtin types many years ago.
>> The justification was that in the presence of type specialization it
>> makes io.write etc "almost" as fast as if it were written directly (i.e.
>> if it were not implemented in terms of stream.string_writer).
>
> Do you know whether this code *actually* gets type specialized?

Right now I doubt it since one of the things that I left out of this
change was the type_spec pragmas that exist for other such predicates --
I'll add them.

Julien.