Generalizing Integers (was Re: Specifying int size in C)

[Clay Phipps]

[The postings referenced below, the 1st of which I missed in original form,
appeared in "comp.arch", for some reason; apologies if this is redundant]

In article <3899 at ficc.uu.net>, 
peter at ficc.uu.net | uunet.uu.net!ficc!peter (Peter da Silva) writes:
>In article <10377 at polyslo.CalPoly.EDU>, 
>cquenel at polyslo.CalPoly.EDU (36 more school days) writes:
>> In 9424 peter at ficc.uu.net (Peter da Silva) sez:
>> >I've suggested this before. I think syntax like:
>> >	int:32	x, y;
>> >	int:36	z;	/* Unisys 1100 compatibility :-> */
>> >	int	a:8, b:9, c:6;
>>
>>[An apparent suggestion that new primitive types be created for C, e.g.:]
>> 	int32_t x,y;
>> 	int16_t c;
>>would probably raise a lot fewer hackles.
>
>... the semantics are not quite as good as int:n would be.
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^
Agreed.  I realize that this is a C-related posting, but has anyone 
yet pointed out that PL/I had relevant features a quarter-century ago ?
The following suggests how that might apply to C.

Da Silva's original examples would be as follows in their tersest form:

    dcl (x, y) fixed bin(31),
        z      fixed bin(35),  /* Unisys/UNIVAC 1100 fullword */
        a      fixed bin(7),
        b      fixed bin(8),
        c      fixed bin(5);

The numbers above are coded as 1 less than above,
but yield the same representation, because the sign bits were implicit
in PL/I -- there was no notion of unsigned binary fixed-point numbers,
a.k.a. unsigned integers.  However, if any FORTRAN or COBOL scalar data 
types were wanting for support in PL/I, I have forgotten what they were.
PL/I also allowed specification of a radix point anywhere in the variable,
e.g.: "fixed bin(31,31)" would indicate that all bits were binary fraction
bits, such that a 32-bit word with the sign bit on and other bits off
would have the value -1.  I doubt that there would be much interest in 
providing arbitrary radix-point placement for data in C.

>For example, 1+(unsigned int:3)7 should be 0. 

I am not up on the fine points of C semantics, so maybe the example
is adequate, but I think you should require something like
    (unsigned int:3)(1+7)
to more clearly indicate the relation of the cast to the expression 
computation.  Otherwise, you will have ambiguity about what is intended
to be done if the expression is assigned to a wide assignment target,
e.g.: any target into which the representation for 8 fits completely. 

PL/I had conversion functions for which precision could be specified, e.g.:
    BINARY(1+7,3)
but PL/I was notorious for the surprises provided by its conversion rules
(which were explicitly *not* standardized), partially a consequence
of defaulting "fixed" to decimal (i.e.: BCD), and (I think) "binary" to 
floating-point, resulting in treatment of "7" as *decimal*, not binary.  
Fixed binary 7, a.k.a. signed integer 7, needed to be coded as "7b" 
(no quotes in the code).  Therefore, it might be necessary with some of 
the "obvious choices" of conversion functions to use that ugly PL/I 
binary-constant notation:
    PRECISION(1b+7b,3)
    FIXED(1b+7b,3)
Fortunately, C is not hindered by a perceived need to provide for BCD, 
and assuming little interest in the arbitrary placement of a radix-point 
in C "int" data, so any conversion rules that needed to be devised 
to support da Silva's idea could probably avoid the surprises that 
can make expression evaluation and conversions so aggravating in PL/I.

The casts suggested by da Silva are certainly preferable to collections of 
predefined conversion functions for languages (such as C) where user-defined 
data types are supported.  I wish Wirth had thought of that when designing 
Pascal.  PL/I doesn't provide named data types, although its "like" attribute 
comes close to that.

>It'd also be a boon for people porting code to weird machines... 
>sometimes you really need an int with a power-of-2 size,
>and it's a pain to emulate that by hand on a 36-bit machine.

ANS PL/I [ANSI X3.53-1976] defined a "default" statement, e.g.:
    default (fixed & bin) precision(31);  /* for IBM 360 & VAX */
    default (fixed & bin) precision(35);  /* for Unisys 1100 & Honeywell */
in which anything declared as both "fixed" and "bin" is assigned either
31 bits + sign, or 35 bits + sign, respectively.  This makes it possible
to ease porting in advance, by not coding the precision for declarations 
of standard-sized integers, declaring them as "fixed bin" only, 
limiting coding of parenthesized precision attributes to declarations 
for which they were independent of target architecture,
e.g.: network communications protocols.
Has the ANSI C committee provided anything like this ?

This discussion isn't very architecturish any more.
I have redirected follow-ups to "comp.lang.misc" and "comp.lang.c";
I encourage follow-ups to those to be directed to only one or the other,
depending upon how the discussion proceeds.
-- 
[The foregoing may or may not represent the position, if any, of my employer, ]
[ who is identified solely to allow the reader to account for personal biases.]
                                              
Clay Phipps                                {ingr,pyramid,sri-unix}!garth!phipps
Intergraph APD, 2400#4 Geng Road, Palo Alto, CA 93403              415/494-8800