[m-rev.] 8, 16 and 32 bit types

[Julien Fischer]

Hi Zoltan,

On Mon, 3 Jul 2017, Zoltan Somogyi wrote:

> Attached is a partial review of the change that introduces {int,uint}{8,16,32}.
> (My web based email client doesn't handle 7000 line messages well.)
>
> Before I finish the review, I think it is important we agree on
> how we should handle two issues that my partial review has found.
>
> The first is whether the cons_ids representing the new types and the
> operations on them should look like this
>
>    ;   int8_eq
>    ;   int16_eq
>    ;   ...
>
> or like this:
>
>    ;    int_eq(signedness, int_size)
>
> While we had one int type, there was no duplication, while we had two,
> having two copies of everything dealing with it was often easier than
> worrying about parameterization. But since we now have eight and will
> soon have ten, I think parameterization is preferable. True, it
> results in slightly larger representations, but I am pretty sure the
> effect will be unmeasurable on most if not all programs.

I don't have any objections to changing it to that; my feeling was
that the flat enumeration made the code generators (i.e. the part of the
compiler that really cares about the distinction between all these
things) a bit more legible (at the cost of making some switches in other
places a bit longer).

> The second is that I believe the values of uint{8,16,32} constants should be
> represented by a uint, not an int, due to the 32 and 64 bit equivalents of
> "an 8 bit signed int can't represent 255".

The values of uint{8,16,32} bit constants should be uint8, uint16 and
uint32 values respectively, since since some parts the compiler (e.g.
compiler/simplify_goal_call.m) may wish to operate on them.  After this
change has bootrapped they will be changed to that.

I haven't had a chance to look the attached review in any detail yet.

Julien.