This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [using gcc book] 5.20 double-word integers
- From: Gabriel Paubert <paubert at iram dot es>
- To: Chris Devers <cdevers at pobox dot com>
- Cc: GCC list <gcc at gcc dot gnu dot org>
- Date: Mon, 1 Sep 2003 18:47:38 +0000
- Subject: Re: [using gcc book] 5.20 double-word integers
- References: <Pine.OSX.4.56.0308232126560.8695@macdaddy.local> <20030826095248.GB7637@iram.es> <Pine.OSX.4.56.0308261045280.1141@macdaddy.local> <20030826174441.GA12461@iram.es> <Pine.OSX.4.56.0308261353500.1141@macdaddy.local> <Pine.OSX.4.56.0309011337020.9933@macdaddy.local>
On Mon, Sep 01, 2003 at 01:41:39PM -0400, Chris Devers wrote:
> Hello again, everyone. I'm finishing up the last round of revisions so
> that the _Using GCC_ manuscript can go out to the printer, which hopefully
> will happen tomorrow.
>
> Here's the first of a handful of last minute questions.
>
>
> On Tue, 26 Aug 2003, Chris Devers wrote:
>
> > On Tue, 26 Aug 2003, Gabriel Paubert wrote:
> >
> > > Finally, when rereading the whole "Double-word Integers" section,
> > > it seems obvious that it was written before the existence of 64 bit
> > > machines, in which registers are twice the size of an int, and often
> > > use exactly the same instructions for 32 and 64 bit operations.
> >
> > In which case, it's yet another section that could really do with a
> > complete rewrite from scratch to bring it more up to date.
> >
> > Barring that, I might just strengthen the note about how word length is
> > sensitive to the hardware you're dealing with, and it may be necessary
> > to refer to platform specific documentation for these things.
>
> With that in mind, I've added a footnote to this section, as follows. The
> only new material at the moment is the @footnote{...} comment after "64
> bits", but to keep things in context here's the whole paragraph & header:
>
> <excerpt>
>
> @node Long Long
> @section Double-Word Integers
> @cindex @code{long long} data types
> @cindex double-word arithmetic
> @cindex multiprecision arithmetic
> @cindex @code{LL} integer suffix
> @cindex @code{ULL} integer suffix
>
> ISO C99 supports data types for integers that are at least 64
> bits@footnote{Note that, in practice, actual word lengths will depend on
> the platform in question, and that as 64-bit processors continue to become
> mainstream, longer word lengths are likely to become common. Consult your
> local documentation as necessary for details about word lengths on your
> platform.} wide, and as an extension GCC supports them in C89 mode and in
> C++. Simply write @code{long long int} for a signed integer, or
> @code{unsigned long long int} for an unsigned integer. To make an integer
> constant of type @code{long long int}, add the suffix @samp{LL} to the
> integer. To make an integer constant of type @code{unsigned long long
> int}, add the suffix @samp{ULL} to the integer.
>
> </excerpt>
>
> Please let me know if this footnote validly summarizes the situation, or
> if there's anything else that should be said. Also, I'm not sure if this
> is the right term to attach the note to, but can't really think of a
> better place to attach it. Suggestions welcome.
Well, the main problem might now be the title of the section. GCC can
produce code for machines whose native register width is 8, 16, 32, or
64 bits. And then the term "word" often means something different in
the architecture manual of the target: 16 bit on Alpha and i386, 32
bits on PPC and S390. Ironically, original Alpha can't even store
or load a word (16 bit) in a single instruction, but I digress...
Now what about a radical proposal? Shrinking this section to the bare
minimum which would mean only mentioning that the C99 long long data
types are also supported in C89 and C++ as an extension (please
somebody correct me if there are subtle differences between the
C89 extension and the C99 mode, I've never noticed any but I've
used long long only very occasionally).
Continuing in the radical direction, I'd also remove the sentences
about the multiplication/shifts/division and other operations. I'd
rather have (in a next version of a manual) a table which describes
architecture per architecture which operations require a library call
and which operations are open-coded. After all, all divides with
a non constant denominator require a library call on Alpha and
others (HPPA, Sparc, IA64?). But this would be a different section.
Sorry to be so late in suggesting this, I imagine that you have very
little time.
Regards,
Gabriel