rex@aussie.COM (Rex Jaeschke) (11/30/90)
%---------------------------------------------------------------
At the Sept '90 meeting of the Numerical C Extensions Group (NCEG), a
new subgroup was formed to address the issue of Extended Integer
Precision. The leader of that group is Randy Meyers of DEC. He's at
uunet!decwrl!tle.dec.com!rmeyers
The following is the question (and comments received) I posed in a
recent electronic poll of vendors/users. If you have an interest in
this area AND you have CONSTRUCTIVE criticism and RESPONSIBLE comments
please pass them on to Randy. I do not expect he or I will monitor
this conference otherwise for such input.
Also, I do a poll every 3 months with 5-6 questions. If anyone wishes
to be considered for inclusion in the polls send me mail describing
your C interests. Only those who respond to polls get the results
(which are also published in each issue of the Journal of C Language
Translation).
%---------------------------------------------------------------
{Extended Integer Types}
At the most recent Numerical C Extensions Group meeting a subgroup
was formed to consider extended integer types. Prior art in this
area comes from one 64-bit machine where the type long long int has
been added. What is your opinion on long long as a solution? Do you
have an interest (or prior art) in a more general solution such as
int16, int32, int64, etc?
++ Comments:
** long long shows how stubborn the C community is in rejecting
innovation from other languages. Our interest is in a more general
solution. We have an extension to C syntax for integer range types,
which lets the user say things like typedef |-32768..32767| int16;.
Not only is this a cleaner syntax than short, long, long long, etc.,
but it also is more portable and offers greater opportunities for
error checking.
** I have a huge dislike of the more general int16, etc., solution.
This is just not portable to all architectures and encodes too much
information in the type. long long seems a bit kludgy to me. Is
there really a need for more than four different integer sizes, even
on a 64-bit architecture?
** We have no prior art in this area; however we are very keen that
some solution to the large file size problem should become `standard'
soon. We prefer that the large file size problem should be solved be
changing C to allow a larger type (rather than by providing new
lseek, etc., functions or by making long int 64 bits wide). long
long int is adequate and likely to become accepted more quickly than
the FORTRAN type syntax.
** The long long int type causes a number of difficulties but can be
implemented easily and usefully. I think a more general extension
such as allowing subranges and specific size specifications would
make more sense though.
** Our machine has 64 bits per word. If long long were added it
would more likely be a 128-bit integer for us. We may even have a
use for it! I'm not sure int16, etc., is a good idea, but I have no
better ideas.
** I think long long int is in the `spirit of C.' I know some people
desperately want bit-count-level control, but I've never needed it.
I dislike int32, etc., partly because I've never needed them and
partly because I don't see how many of them there should be or what a
compiler should do if it can't provide the size requested. Also,
they're ugly and look more like PL/I than C.
** We have received several requests from our users for a 64-bit
integer even thought ours is not a 64-bit machine. We plan to
implement such a type in the future.
** I prefer a header with intNN defined for every reasonable NN in
terms of the base types supplied by the compiler. I think
programmers should avoid cute optimizations on word length to save
storage because the cost is broken programs when something gets
bigger or longer than they ever imagined. Just use int unless there
is overriding reason.
** long long makes the most sense. To have specificational types
such as int32, etc., would mean a major change in the language
specification and rightly belongs in a new language.
** long long is a workable concession to nonportable programs. But
it makes the clear statement that there was no good choice. Of
course adding more keywords is not any better. Using more and more
such combinations will only make things much worse. Some form of
extensible specification would be better. For the meantime, I would
think that having long be your wider-than-32-bit integer and int be
32 bits is a reasonable alternative.
** long long seems OK to me. When 128 comes around we'll rethink,
but that will be 20 years.
** No real opinions here although I can't help commenting that people
with 36-bit machines might want int18 and int36 as well.
** We have no pressing need for extended types.
** I cannot support the use of reserved identifiers as additional
keywords. long long has the advantage that it is a conforming
extension. However, I see no real need to access all possible
integer sizes.
** We already support long long.
** I do not believe that long long int guarantees a 64-bit integral
type. The best that could be guaranteed is at least 64 bits.
Currently, there are four different precisions possible for integral
types. This allows 8-bit char, 16-bit short, 32-bit int, and 64-bit
long. I am against this proposal.
** My preference is to introduce the concept of integer ranges as
found in Pascal. Extremely large integer types can be implemented as
typedefs using large integer ranges. I think that Pascal style
ranges afford better compile-time analysis than the int32, int64
variants found in FORTRAN.
** In our implementation, short, int, and long in essence all use 64
bits. Therefore, long long int should not be used to designate a 64
bit object.
%---------------------------------------------------------------
Rex
----------------------------------------------------------------------------
Rex Jaeschke | Journal of C Language Translation | C Users Journal
(703) 860-0091 | 2051 Swans Neck Way | DEC PROFESSIONAL
rex@aussie.COM | Reston, Virginia 22091, USA | Programmers Journal
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------