phipps@garth.UUCP (Clay Phipps) (05/03/89)
[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@ficc.uu.net>, peter@ficc.uu.net | uunet.uu.net!ficc!peter (Peter da Silva) writes: >In article <10377@polyslo.CalPoly.EDU>, >cquenel@polyslo.CalPoly.EDU (36 more school days) writes: >> In 9424 peter@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