The 64bit future

[kid joe]

Hi,

I was wondering how people here look at the 64bit question from a C
perspective.

Have people already started to write programs solely for 64bit
architectures and not worry about 32bit compatibility? Or how far down the
line is that likely to be?

I guess the main things from a C programmers point of view are
1) 64bit pointers, ability to access regions of memory larger than 4GB (eg
memory mapping large files etc)
2) save some typing by using long instead of long long to guarantee
holding integers bigger than 2^32.

Cheers,
Joe


--

...................... o _______________ _,
` Good Evening! , /\_ _| | .-'_|
`................, _\__`[_______________| _| (_|
] [ \, ][ ][ (_|

 

[jacob navia]

Hi,

I was wondering how people here look at the 64bit question from a C
perspective.

Have people already started to write programs solely for 64bit
architectures and not worry about 32bit compatibility? Or how far down the
line is that likely to be?

I guess the main things from a C programmers point of view are
1) 64bit pointers, ability to access regions of memory larger than 4GB (eg
memory mapping large files etc)

Drawback: 64 bit pointers take twice as much space as 32 bit ones.
Most programs do not need more than 4GB RAM. Most of those 64 bits
are just wasted space.

2) save some typing by using long instead of long long to guarantee
holding integers bigger than 2^32.

Not with lcc-win for windows. In lcc-win for windows you get 32 bit
longs, since Microsoft decided that way.

 

[Carl]

Hi,

I was wondering how people here look at the 64bit question from a C
perspective.

Have people already started to write programs solely for 64bit
architectures and not worry about 32bit compatibility? Or how far down the
line is that likely to be?

I guess the main things from a C programmers point of view are
1) 64bit pointers, ability to access regions of memory larger than 4GB (eg
memory mapping large files etc)
2) save some typing by using long instead of long long to guarantee
holding integers bigger than 2^32.

Cheers,
Joe

I have, but I am programming for Nvidia GPUs. The GPU uses 64 bit
pointers, so it makes sense to use them on the host as well. I don't
use that much memory on the host machine, so space is not an issue.

 

[Paul Hsieh]

I was wondering how people here look at the 64bit question from a C
perspective.

Have people already started to write programs solely for 64bit
architectures and not worry about 32bit compatibility? Or how far down the
line is that likely to be?

Lol! If I were to guess about some of the people in this newsgroup, I
would say they'll get around to considering 64 bit pointers right
around the time the industry standardizes on 128 bit pointers (which
will be about 30 years from now, if anyone was curious.) For more
serious programmers in this newsgroup, support for 64 bit is a very
old issue ("we support that today"). You can, of course, write code
that is pointer size agnostic (in fact, in the case of pointer sizes,
this should be the usual case.)

I guess the main things from a C programmers point of view are
1) 64bit pointers, ability to access regions of memory larger than 4GB (eg
memory mapping large files etc)

C does not support "memory mapping of large files" even though real
programmers do. In any event nearly all desktop systems sold today
support a 64bit programming model. The size of a pointer in C is
considered opaque. If you want to alias it to platform defined scalar
integer type, you should use intptr_t or uintptr_t.

2) save some typing by using long instead of long long to guarantee
holding integers bigger than 2^32.

No, C screwed the pooch on that one long time ago. On most systems
long just means 32 bits, even though a longer integer type clearly is
implemented on the system. The problem, of course, is that you can
"implement" any bitness for a scalar you like in software, so why
would you assign a common basic type to something you have slow
support for rather than something less likely to be used?

In the C99 standard the committee took a very belated step in the
right direction by including a header file called <stdint.h> . It
defines types like:

int64_t

and so on which have exactly as many bits as you would expect. This
way, programmers can make informed choices and default choices that
still make sense. You should ignore whatever the definition of int,
long or long long is in specifics. I am sure it might make some
people happy to know they have some useful definition, but you should
just treat them all as if they were at least 16 bits, and give them no
other consideration (other than type strictness). If you care at all
about specific size semantics, just use the stdint.h definitions.

If you have an older compiler set or you want to write portable code,
I would recommend you use my substitute for stdint.h here:
http://www.pobox.com/~qed/pstdint.h . It has the advantage of
implementing the types for older non-C99 compliant compilers while
exposing stdint.h exactly for those compilers that are C99 compliant.
So in a sense you get maximal compatibility.

 

[Keith Thompson]

No, C screwed the pooch on that one long time ago. On most systems
long just means 32 bits, even though a longer integer type clearly is
implemented on the system.

C didn't screw the pooch; certain C implementations did.

[...]

If you have an older compiler set or you want to write portable code,
I would recommend you use my substitute for stdint.h here:
http://www.pobox.com/~qed/pstdint.h . It has the advantage of
implementing the types for older non-C99 compliant compilers while
exposing stdint.h exactly for those compilers that are C99 compliant.
So in a sense you get maximal compatibility.

Doug Gwyn some time ago wrote a set of C99-ish headers for use with
C90 implementations. They're available at
<http://www.lysator.liu.se/c/q8/index.html>. I haven't compared the
two implementations, and I'm not recommending one over the other, just
mentioning an alternative.

 

[Keith Thompson]

blargg said:

[...]
2) save some typing by using long instead of long long to
guarantee holding integers bigger than 2^32.

No, C screwed the pooch on that one long time ago. On most
systems long just means 32 bits, even though a longer integer
type clearly is implemented on the system.

C didn't screw the pooch; certain C implementations did.

[...]

Then why did C add the ridiculous "long long" type?

Excellent question. And if they felt obliged to add such a
ridiculous type, why did they give it such a ridiculous name?

Backward compatibility via reuse of an existing keyword. What would
you suggest?

And why is "long long" any more ridiculous than, say, "long double"?

C would have benefited from a more coherent and extensible integer
type system rather than a fixed set of combinations of keywords (char,
short int, int, long int, etc.), but that ship sailed a long time ago.

 

[Phil Carmody]

blargg said:

[...]
2) save some typing by using long instead of long long to
guarantee holding integers bigger than 2^32.

No, C screwed the pooch on that one long time ago. On most
systems long just means 32 bits, even though a longer integer
type clearly is implemented on the system.

C didn't screw the pooch; certain C implementations did.

[...]

Then why did C add the ridiculous "long long" type?

Excellent question. And if they felt obliged to add such a
ridiculous type, why did they give it such a ridiculous name?

Is it that ridiculous? Does it not invite an infinitude of
future larger types with absolutely no invasion into the users'
namespace? Having said that, I hope that my compiler warns me
when I try to assign a long long long long long long to a long
long long long long!

Phil

 

[Ian Collins]

On Apr 29, 3:18 pm, kid joe <spa

No, C screwed the pooch on that one long time ago. On most systems
long just means 32 bits, even though a longer integer type clearly is
implemented on the system.

Where most == windows.

 

[jacob navia]

Keith Thompson said:


very long

Okay, in theory it could break existing code - but so did the
removal of implicit int. And it's scalable.


long double is silly too. So is double.

double should be "long float".
long double should be "very long float".


I know, I know.

Microsoft proposed int64, what is much more extensible of course.
lcc-win implements int128 in its 64 bit version. I asked in
comp.std.c if they will use long long long and everybody agreed
that I should use int128 instead.

 

[Guest]

Keith Thompson said:




very long

Okay, in theory it could break existing code - but so did the
removal of implicit int. And it's scalable.


long double is silly too.  So is double.

double should be "long float".
long double should be "very long float".

double plus ungood


<snip>

 

[lawrence.jones]

blargg said:

Excellent question. And if they felt obliged to add such a
ridiculous type, why did they give it such a ridiculous name?

Because it was wide spread existing practice. (Much of the committee
wasn't particularly fond of it, either.)

 

[Keith Thompson]

double plus ungood

++!good

 

[Keith Thompson]

Make long 64 bits on such machines. This actually preserves
compatibility with code that assumes a long can store a pointer, and
that it's the largest integral type.

But it doesn't preserve compatibility with code that assumes long is
32 bits. Unfortunately, such code is all too common. If you're a
vendor, do you punish your users for writing non-portable code?

 

[Paul Hsieh]

Where most == windows.

I'd be pretty surprised if this wasn't the majority even by platform
count these days. There are no new 32 bit microcontrollers being
designed these days; 64 bit is pretty much the minimum for anything
new, and if you want to use "off the shelf code" especially with all
that open source stuff now available you are going to want to be
compatible with what works on most systems.

Can you name something with a significant developer base, designed in
the last 10 years, which sets long to more than 32 bits?

 

[Keith Thompson]

I'd be pretty surprised if this wasn't the majority even by platform
count these days. There are no new 32 bit microcontrollers being
designed these days; 64 bit is pretty much the minimum for anything
new, and if you want to use "off the shelf code" especially with all
that open source stuff now available you are going to want to be
compatible with what works on most systems.

Can you name something with a significant developer base, designed in
the last 10 years, which sets long to more than 32 bits?

I've seen 64-bit longs on a number of 64-bit Unix-like systems,
including SPARC/Solaris, Alpha/OSF, PowerPC/AIX, IA-64/, and
x86_64/Linux. In some cases there's a compiler option to choose
between 32-bit and 64-bit mode.

 

[Keith Thompson]

You mean, do the users punish themselves? Looks like they are instead able
to punish all future C programmers.

No, if I had meant that, I would have said so.

Say you're a compiler vendor, depending on customers giving you
money for your product. Your customers have been writing (bad,
non-portable) code for 32-bit systems that assumes long is exactly
32 bits. You want to start selling a version of your compiler for
64-bit systems. If you make long 32 bits, your customers will be
able to recompile their code, and it will still work. If you make
long 64 bits, your customers will have to go back and change their
code (and the modified code will probably be just as non-portable
as the original, just in different ways). Or, more likely, they'll
start buying compilers from your competitor who's still providing
32-bit longs.

If you choose to do the "right thing" and make long 64 bits, I'll
admire your principles, but I doubt that it will turn out well for
your bottom line. My personal inclination would be to provide 64-bit
long; that's probably one of the many reasons I'm not in marketing.

Yes, it's a real problem, and I'd love to see a real solution, but I
don't think it's the vendors' fault.

On the other hand, in the Unix/Linux world compilers *do* seem to be
providing 64-bit long on 64-bit systems, so maybe my entire argument
falls apart, or maybe there's some fundamental difference between
Windows C development and Unix/Linux C development.

 

[Keith Thompson]

I don't use Linux, but I get the idea their solution is to basically just
recompile everything, rather than try to maintain binary compatibility.

I've also seen sytems that provide 32-bit and 64-bit versions of all
the system libraries. The option that tells the compiler whether to
generate 32-bit or 64-bit code also tells the linker which versions of
the system libraries to link.

 

[Stephen Sprunk]

I'd be pretty surprised if this wasn't the majority even by platform
count these days.

Virtually all 64-bit platforms are I32LP64; IL32LLP64 is mostly a
Windows thing.

Can you name something with a significant developer base, designed in
the last 10 years, which sets long to more than 32 bits?

The "significant developer base" is a sticking point, since in terms of
developer count Windows has >90% share...

Linux is the most obvious I32LP64 system, Solaris is another major one,
and I think OS/X is the same. The various Alpha OSes were, too. I'm
not sure about HP/UX, AIX, IRIX, etc.

S

 

[CBFalconer]

blargg said:
.... snip ...


Excellent question. And if they felt obliged to add such a
ridiculous type, why did they give it such a ridiculous name?

Obviously to avoid adding to the list of reserved words.

 

[CBFalconer]

Make long 64 bits on such machines. This actually preserves
compatibility with code that assumes a long can store a pointer,
and that it's the largest integral type.

FYI you are at least 10 years too late with that suggestion. C99
has been out since 1999.