Re: how to detect the compile is 32 bits or 64 bits?



Walter Roberson wrote:
In article <0f3Bg.2584$9T3.1111@xxxxxxxxxxxxxxxxxxxxxxxxxx>,
Tim Prince <tprince@xxxxxxxxxxxxxxxxxxx> wrote:
steve yee wrote:
i want to detect if the compile is 32 bits or 64 bits in the source
code itself. so different code are compiled respectively. how to do
this?

You invite bugs, as well as taking the question off the topic of standard C, if you write source code which has to change.

Not necessarily.

The usual question is about (sizeof)<various pointer types>. If your question is simply about (sizeof)int, you create problems by assuming it is determined by whether you have a 32- or 64-bit platform. If you insist on unions of pointers and ints, knowing whether it is 32 or 64 bits won't save you. More so, if you are one of those who writes code which depends on (sizeof)(size_t x).

You appear to have read a fair bit into the poster's question
that I don't think is justified by what the poster wrote.
OP didn't explain what the reason for non-portable code might be. Certainly, there wasn't anything about finding the largest efficient data types.

Suppose I have an algorithm, such as a cryptography algorithm, that
operates on chunks of bits at a time. The algorithm is the same
(except perhaps for a few constants) whether I'm computing with 32 or
64 bits, but the chunk size differs for the two cases. In such a case,
I -could- write the code using only the minimum guaranteed size, but on most platforms it would be noticably more efficient to use
the larger chunk size *if the platform supports it*. The constants
for the algorithm could probably be computed at run-time and a
generic algorithm used, but in the real world, having the constants
available at compile time increases compiler optimization opportunities
leading to faster code.


So, your interpretation of 32- bit vs 64-bit is based on whether there is an efficient implementation of 64-bit int. It's certainly likely, but not assured, that a compiler would choose (sizeof)int in accordance with efficiency. For example, most Windows compilers have 32-bit int and long even on platforms which have efficient 64- and (limited) 128-bit instructions, where linux for the same platform supports 64-bit int.
If this is your goal, you need a configure script which checks existence of various candidate data types, which don't necessarily appear in <stdint.h>, and tests their efficiency.
.



Relevant Pages

  • Re: integer size and portability-a wishful controversy
    ... >> BTW, there is no point in using the old Turbo C compiler, unless ... I do NOT consider programs relying on int having at least 32 bits as ... use the PC as an almost freestanding platform for developing/testing ... device drivers for various pieces of PC hardware. ...
    (comp.lang.c)
  • Re: interesting use of NEXT SENTENCE vs. CONTINUE
    ... These days I don't do compiler maintenance, but I HAVE done in the past, so ... You had a chance to point out how adherence to the standard can improve ... >> compile it WITH MINOR MODIFICATIONS for a specific platform. ... > platform-specific extension to COBOL ...
    (comp.lang.cobol)
  • Re: c dll to c#
    ... just name me a C compiler that targets the Microsoft Windows ... platform who has a 64 bit "built-in" long type. ... mapping for an int and a long looks like: ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: interesting use of NEXT SENTENCE vs. CONTINUE
    ... I DID think any old compiler would be able to ... > compile it WITH MINOR MODIFICATIONS for a specific platform. ... > not going to go to the Standard to see what SHOULD work. ... If you write your COBOL code avoiding the things that are marked as ...
    (comp.lang.cobol)
  • printf anomaly
    ... My understanding is that the 1000 will default to int ... Then it will be promoted to unsigned long (since on our platform long ... and printf is a variadic ... I must be missing something or the compiler is broken? ...
    (comp.lang.c)