--------- Received message begins Here ---------
> From dpw@groucho.doc.ic.ac.uk Tue Jan 11 16:04:43 2000
> Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil> writes:
> > >Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil> writes:
> > >> And even then it is limited to 64 bits on a 64 bit system (unless the
> > >> compiler is non-standard - ie "long long" type of thing).
> > >
> > >long long is in ISO/ANSI C99.
> >
> > yes it is. but the number of bits is not. On a 32 bit system "long long" is
> > 64 bits. On a 64bit system it is 128. And if you need more bits that
> > that you are out of luck. "long long" is imprecise, I'd prefer a construct
> > like "int var: 64". This way I know exactly how many bits are available.
> > If I need 128 bits for something (or even 4096) then I can define them. Or
> > is there going to be a "long long long long" for 128 bits, and "long long
> > long long long long .... long" to reach 4096?
>
> Indeed. I don't expect to ever find much use for long long, because
> C99 also comes with <inttypes.h>. Granted, it's not quite as general
> as the scheme you propose, but it looks like it will do.
>
> (<inttypes.h> is in some ways more general than your scheme. If I say
> "int var : 64", does that mean the smallest signed integer type
> holding 64-bits, or the fastest one (e.g. one that can be held in a
> register), or what? <inttypes.h> deals with this. Of course, your
> scheme could easily be extended, but it shows that once you start to
> add facilities for declaring variables based on type properties, there
> are a lot more properties to consider than just bit-width. If you want
> PL/I, you know where to find it ;-))
If the hardware does 64 bit native arithmetic, I would expect it to use it.
If the hardware is more extensive, then it would use it, and reduce it down
to 64 bits just as it does for a normal bit field.
If I wanted it in a register, then I would say: register int var:64; This
should work since the compiler can already ignore the register declaration
if it determines that it isn't appropriate anyway.
If the hardware is more limited, then I would expect it to use a runtime
library to implement the correct arithmetic, in the most efficient manner
for that hardware.
If I wanted an unsigned value I would say "unsigned int var:64", or
"unsigned var:64".
>
> The main point of long long is that it guarantees that there will be a
> 64-bit type, and so <inttypes.h> has definitions for int64_t
> etc. Since C99 does not require a 128-bit extended integer type,
> <inttypes.h> does not have to define int128_t etc. But it does reserve
> the namespace, and it would take a very brain-dead vendor to have such
> a type but omit the corresponding definitions from <inttypes.h>.
>
> The other advantage of <inttypes.h> is that, even for platforms
> without long long, it is very easy to write your own version of that
> file and use it in your own projects on non-C99 platforms. Similar
> techniques are already widely used, of course; all C99 does is fix the
> names.
Yup. Fixes the names, but doesn't fix the functionality. 128 bit integers
become usefull with IP version 6. A 4K bit number would be usefull with
encryption (and poll vectors? maybe not). The construct would/could
even simplify inittypes.h. It would even be usefull for compatability
between various hardware platforms. At least a users need for a specific
number of bits could be met in all cases (even if a bit inefficently).
It really depends on the application as to where it would be usefull.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:19 EST