[gentoo-user] Re: Compiling 32 bit library on x86_64

[gentoo-user] Re: Compiling 32 bit library on x86_64

[Nikos Chantziaras]

On 04/30/2010 03:09 PM, David W Noon wrote:
> On Fri, 30 Apr 2010 12:10:02 +0200, Roger Mason wrote about
> [gentoo-user] Compiling 32 bit library on x86_64:
>
>> Hello,
>>
>> I need to compile a 32 bit version of libtermcap on an x86_64
>> (multilib) system.  Can someone tell me how to set up CFLAGS?  This is
>> what I have at the moment:
>>
>> CFLAGS="-O2 -m32 -march=native -msse3 -pipe"
>> CXXFLAGS="-O2 -m32 -march=native -msse3 -pipe"
>
> The -march=native will shoot you in the foot. Pick a 32-bit
> architecture and use that instead; e.g. -march=i686
>
> Then, -msse3 could also be problematic, unless the target is a very late
> model Pentium 4.  I would ditch that too.

None of those options are problematic.  -march=native has nothing to do 
with 32/64 bit.  Every 64-bit CPU is 32-bit compatible and has zero 
consequence.

I think you fell into the logical trap that 32-bit CPUs are not 64-bit 
compatible but it's OK vice versa :)  Meaning you can't use "-m64 
-march=i686".  But you *can* and *should* use "-m32 -march=core2".

Re: [gentoo-user] Re: Compiling 32 bit library on x86_64

[David W Noon]

[-- Attachment #1: Type: text/plain, Size: 8899 bytes --]

On Fri, 30 Apr 2010 15:20:02 +0200, Nikos Chantziaras wrote about
[gentoo-user] Re: Compiling 32 bit library on x86_64:

>On 04/30/2010 03:09 PM, David W Noon wrote:
>> On Fri, 30 Apr 2010 12:10:02 +0200, Roger Mason wrote about
>> [gentoo-user] Compiling 32 bit library on x86_64:
>>
>>> Hello,
>>>
>>> I need to compile a 32 bit version of libtermcap on an x86_64
>>> (multilib) system.  Can someone tell me how to set up CFLAGS?  This
>>> is what I have at the moment:
>>>
>>> CFLAGS="-O2 -m32 -march=native -msse3 -pipe"
>>> CXXFLAGS="-O2 -m32 -march=native -msse3 -pipe"
>>
>> The -march=native will shoot you in the foot. Pick a 32-bit
>> architecture and use that instead; e.g. -march=i686
>>
>> Then, -msse3 could also be problematic, unless the target is a very
>> late model Pentium 4.  I would ditch that too.
>
>None of those options are problematic.  -march=native has nothing to
>do with 32/64 bit.  Every 64-bit CPU is 32-bit compatible and has zero 
>consequence.
>
>I think you fell into the logical trap that 32-bit CPUs are not 64-bit 
>compatible but it's OK vice versa :)  Meaning you can't use "-m64 
>-march=i686".  But you *can* and *should* use "-m32 -march=core2".

No, I stand by what I wrote.

The -march=native option tells the compiler to issue the CPUID
instruction to determine the architecture.  This means that on an amd64
box it will return data for either an AMD K8 or an Intel Pentium D
architecture.  This, in turn, allows the compiler to generate K8
instructions that are not valid on IA32 processors.  It even allows
the compiler to use 64-bit registers, including the additional
registers that were not in an IA32 processor.

The -m32 option instructs the compiler to generate code with 32-bit
pointers and relocation dictionary. It does not constrain the compiler
to generate code that will definitely run on an IA32 processor, but it
does ensure that the code can be linked with 32-bit libraries.

So, if one is compiling on, say, a Core2 Duo and one uses -march=native
and -m32, the compiler can use all kinds of instructions valid on the
Core2 Duo, but limits addressing to 32-bit.

From the info pages for GCC:

3.17.14 Intel 386 and AMD x86-64 Options
----------------------------------------

These `-m' options are defined for the i386 and x86-64 family of
computers:

`-mtune=CPU-TYPE'
     Tune to CPU-TYPE everything applicable about the generated code,
     except for the ABI and the set of available instructions.  The
     choices for CPU-TYPE are:
    _generic_
          Produce code optimized for the most common IA32/AMD64/EM64T
          processors.  If you know the CPU on which your code will run,
          then you should use the corresponding `-mtune' option instead
          of `-mtune=generic'.  But, if you do not know exactly what
          CPU users of your application will have, then you should use
          this option.

          As new processors are deployed in the marketplace, the
          behavior of this option will change.  Therefore, if you
          upgrade to a newer version of GCC, the code generated option
          will change to reflect the processors that were most common
          when that version of GCC was released.

          There is no `-march=generic' option because `-march'
          indicates the instruction set the compiler can use, and there
          is no generic instruction set applicable to all processors.
          In contrast, `-mtune' indicates the processor (or, in this
          case, collection of processors) for which the code is
          optimized.

    _native_
          This selects the CPU to tune for at compilation time by
          determining the processor type of the compiling machine.
          Using `-mtune=native' will produce code optimized for the
          local machine under the constraints of the selected
          instruction set.  Using `-march=native' will enable all
          instruction subsets supported by the local machine (hence the
          result might not run on different machines).

    _i386_
          Original Intel's i386 CPU.

    _i486_
          Intel's i486 CPU.  (No scheduling is implemented for this
          chip.)

    _i586, pentium_
          Intel Pentium CPU with no MMX support.

    _pentium-mmx_
          Intel PentiumMMX CPU based on Pentium core with MMX
          instruction set support.

    _pentiumpro_
          Intel PentiumPro CPU.

    _i686_
          Same as `generic', but when used as `march' option, PentiumPro
          instruction set will be used, so the code will run on all
          i686 family chips.

    _pentium2_
          Intel Pentium2 CPU based on PentiumPro core with MMX
          instruction set support.

    _pentium3, pentium3m_
          Intel Pentium3 CPU based on PentiumPro core with MMX and SSE
          instruction set support.

    _pentium-m_
          Low power version of Intel Pentium3 CPU with MMX, SSE and
          SSE2 instruction set support.  Used by Centrino notebooks.

    _pentium4, pentium4m_
          Intel Pentium4 CPU with MMX, SSE and SSE2 instruction set
          support.

    _prescott_
          Improved version of Intel Pentium4 CPU with MMX, SSE, SSE2
          and SSE3 instruction set support.

    _nocona_
          Improved version of Intel Pentium4 CPU with 64-bit
          extensions, MMX, SSE, SSE2 and SSE3 instruction set support.

    _core2_
          Intel Core2 CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3
          and SSSE3 instruction set support.

    _k6_
          AMD K6 CPU with MMX instruction set support.

    _k6-2, k6-3_
          Improved versions of AMD K6 CPU with MMX and 3dNOW!
          instruction set support.

    _athlon, athlon-tbird_
          AMD Athlon CPU with MMX, 3dNOW!, enhanced 3dNOW! and SSE
          prefetch instructions support.

    _athlon-4, athlon-xp, athlon-mp_
          Improved AMD Athlon CPU with MMX, 3dNOW!, enhanced 3dNOW! and
          full SSE instruction set support.

    _k8, opteron, athlon64, athlon-fx_
          AMD K8 core based CPUs with x86-64 instruction set support.
          (This supersets MMX, SSE, SSE2, 3dNOW!, enhanced 3dNOW! and
          64-bit instruction set extensions.)

    _k8-sse3, opteron-sse3, athlon64-sse3_
          Improved versions of k8, opteron and athlon64 with SSE3
          instruction set support.

    _amdfam10, barcelona_
          AMD Family 10h core based CPUs with x86-64 instruction set
          support.  (This supersets MMX, SSE, SSE2, SSE3, SSE4A,
          3dNOW!, enhanced 3dNOW!, ABM and 64-bit instruction set
          extensions.)

    _winchip-c6_
          IDT Winchip C6 CPU, dealt in same way as i486 with additional
          MMX instruction set support.

    _winchip2_
          IDT Winchip2 CPU, dealt in same way as i486 with additional
          MMX and 3dNOW!  instruction set support.

    _c3_
          Via C3 CPU with MMX and 3dNOW! instruction set support.  (No
          scheduling is implemented for this chip.)

    _c3-2_
          Via C3-2 CPU with MMX and SSE instruction set support.  (No
          scheduling is implemented for this chip.)

    _geode_
          Embedded AMD CPU with MMX and 3dNOW! instruction set support.

     While picking a specific CPU-TYPE will schedule things
     appropriately for that particular chip, the compiler will not
     generate any code that does not run on the i386 without the
     `-march=CPU-TYPE' option being used.

`-march=CPU-TYPE'
     Generate instructions for the machine type CPU-TYPE.  The choices
     for CPU-TYPE are the same as for `-mtune'.  Moreover, specifying
     `-march=CPU-TYPE' implies `-mtune=CPU-TYPE'.

[snip]

The above options determine the instruction set and instruction
scheduling, and "native" uses whatever hardware platform is used for
compilation.

[continuing]

`-m32'
`-m64'
     Generate code for a 32-bit or 64-bit environment.  The 32-bit
     environment sets int, long and pointer to 32 bits and generates
     code that runs on any i386 system.  The 64-bit environment sets
     int to 32 bits and long and pointer to 64 bits and generates code
     for AMD's x86-64 architecture. For darwin only the -m64 option
     turns off the `-fno-pic' and `-mdynamic-no-pic' options.

The above is slightly misleading, as it should say "code that loads on
any i386" rather than "code that runs on any i386".  It is all about
setting the width for pointers and integers.
-- 
Regards,

Dave  [RLU #314465]
======================================================================
dwnoon@ntlworld.com (David W Noon)
======================================================================

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-user] Re: Compiling 32 bit library on x86_64

[Nikos Chantziaras]

On 04/30/2010 07:29 PM, David W Noon wrote:
> On Fri, 30 Apr 2010 15:20:02 +0200, Nikos Chantziaras wrote about
> [gentoo-user] Re: Compiling 32 bit library on x86_64:
>
>> On 04/30/2010 03:09 PM, David W Noon wrote:
>>> On Fri, 30 Apr 2010 12:10:02 +0200, Roger Mason wrote about
>>> [gentoo-user] Compiling 32 bit library on x86_64:
>>>
>>>> Hello,
>>>>
>>>> I need to compile a 32 bit version of libtermcap on an x86_64
>>>> (multilib) system.  Can someone tell me how to set up CFLAGS?  This
>>>> is what I have at the moment:
>>>>
>>>> CFLAGS="-O2 -m32 -march=native -msse3 -pipe"
>>>> CXXFLAGS="-O2 -m32 -march=native -msse3 -pipe"
>>>
>>> The -march=native will shoot you in the foot. Pick a 32-bit
>>> architecture and use that instead; e.g. -march=i686
>>>
>>> Then, -msse3 could also be problematic, unless the target is a very
>>> late model Pentium 4.  I would ditch that too.
>>
>> None of those options are problematic.  -march=native has nothing to
>> do with 32/64 bit.  Every 64-bit CPU is 32-bit compatible and has zero
>> consequence.
>>
>> I think you fell into the logical trap that 32-bit CPUs are not 64-bit
>> compatible but it's OK vice versa :)  Meaning you can't use "-m64
>> -march=i686".  But you *can* and *should* use "-m32 -march=core2".
>
> No, I stand by what I wrote.

You are wrong.


> The -march=native option tells the compiler to issue the CPUID
> instruction to determine the architecture.  This means that on an amd64
> box it will return data for either an AMD K8 or an Intel Pentium D
> architecture.  This, in turn, allows the compiler to generate K8
> instructions that are not valid on IA32 processors.  It even allows
> the compiler to use 64-bit registers, including the additional
> registers that were not in an IA32 processor.

The OP was not interested whether the code runs on all IA32 processors. 
  Just on his.  Yes, if you compile with "-m32 -march=native" the code 
will not run everywhere else.  But I fail to see what this has to do 
with 32-bit vs 64-bit; it also happens if you omit "-m32".


> The -m32 option instructs the compiler to generate code with 32-bit
> pointers and relocation dictionary. It does not constrain the compiler
> to generate code that will definitely run on an IA32 processor, but it
> does ensure that the code can be linked with 32-bit libraries.
>
> So, if one is compiling on, say, a Core2 Duo and one uses -march=native
> and -m32, the compiler can use all kinds of instructions valid on the
> Core2 Duo, but limits addressing to 32-bit.

Yes, which is what we want.  Again, the OP was not interested whether 
the code runs on other machines.  If that was the case, he would not 
have used -march=native in the first place.

And I have proof too.  Compile whatever you want with -m32 
-march=native.  It will work just fine.