RE: 64 bit
RE: 64 bit
- Subject: RE: 64 bit
- From: Norm Green <email@hidden>
- Date: Tue, 25 Dec 2007 08:03:17 -0800
Title: RE: 64 bit
We recently ported a very large project (1000 KLOC) from 32 to 64 bit. To do so we did the following:
We wrote sh/perl/awk scripts to do this:
-Change all "long" to "int"
-Change all "unsigned long" to "unsigned int"
In future:
-Use int64_t if you want signed 64 bit int.
-Use uint64_t if you want unsigned 64 bit int.
-Pointers and references generally take care of themselves unless you are doing something weird.
Then, in each source module, after all SYSTEM #include statements (which will still use long in places):
#undefine long
#define long +++unsafe usage of type long. Please use int instead.+++
-This prevents anyone from adding new long/unsigned long declarations to the code.
-compile using -m64
The result is code that can built in either 32 or 64 bit mode. This worked well for us.
Hope this is helpful.
Norm Green
GemStone Systems Inc.
-----Original Message-----
From: David Fang [mailto:email@hidden]
Sent: Monday, December 24, 2007 5:13 PM
To: Alastair Houghton
Cc: Xcode Users
Subject: Re: 64 bit
>> One option is to use -m64, which results in 64b long.
>
> In general that's an extremely bad idea. It fundamentally changes the ABI,
> so calling system routines (even fundamental things like the C runtime
> library) might not work.
Hi,
I should qualify that -m64 means one should be explicitly using
the an LP64 ABI, which may not be the default on other 64b capable
systems. (Don't expect it to work on 32b machines either!) This is only
useful if the dependent libraries (libc, stdc++) are available in the 64b
ABI. Fortunately, they are available for darwin, and the static and
dynamic linkers will "do the right thing" in selecting the correct
architecture/ABI.
>> This gets around having to use the pedantically rejected "long long".
>> (ints are still 32b, pointers are 64b.)
>
> ...(and any "long" parameters to APIs you were using are going to get passed
> as 64-bit values when the API expects them to be 32-bit)...
Correct me if I'm wrong, but the linker should recognize what
objects/archives were built for ABI32 vs. ABI64 (see otool -L, and
'file'), and avoid any cross-linking between the two. Is there another
way to 'break' the API that I'm missing? (There may be, I haven't tried
that hard.)
>> If you need *exactly* 64b, look for types like "int64_t" in the system's
>> type headers.
>
> <inttypes.h> is probably the best place if you want portability, since it's
> defined by C99 but was already present on some systems prior to that. I tend
> to include <stdint.h> myself, but then I only care about systems with C99.
>
> BSD also defines some similar types (in <sys/types.h>), though the unsigned
> variants have an additional underscore (i.e. u_int16_t versus the C99
> uint16_t).
I concur. This often requires some more configure-style checks to
determine which types are in fact available, which is a regular practice
to me, but not necessarily others. For a little more work, this choice
gives good mileage/portability.
Fang
David Fang
Computer Systems Laboratory
Electrical & Computer Engineering
Cornell University
http://www.csl.cornell.edu/~fang/
-- (2400 baud? Netscape 3.0?? lynx??? No problem!)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden