University of Iowa College of Liberal Arts & Sciences

  Computer Science | Mathematics | Statistics and Actuarial Science | Applied Mathematical and Computational Sciences | Informatics

Mathematical Sciences Computer Support Group

Red Hat Enterprise Linux Workstation Processor Compiling FAQ


What is this "AMD64/EMT64" stuff all about?

What do "x86" and "x86_64" mean?

How do I determine if the machine is 32 or 64 bit?

Why are the AMD64/EMT64 processors better than standard 32-bit AMD/Intel processors?

Can I run 32-bit applications on the AMD64/EMT64 machines? How about 64-bit applications on the 32-bit machines?

What are the technical limits imposed by the Linux kernel, the AMD64 processor, and the RHEL load?

How to I compile 32/64 -bit applications on 32/64 -bit processors using gcc?

How is runtime library loading handled? Where are the 32/64 -bit libraries located?

How do I know if a program or library is 32-bit or 64-bit?

Example: A sample compilation/run of a simple "helloworld" program.

Where can I go for more information about C?

Are there any commercial compilers available like Intel?


What is this "AMD64" and or "EMT64" stuff all about?

"AMD64" is the name given to AMD's 64-bit line of x86-compatible processors. The AMD64 processors are commenly referred to as "Opteron" processors; however, "Opteron" is a specific model of processor in the line. The AMD64 processors support both existing 32-bit x86 applications as well as 64-bit x86_64 applications. Intel has finally decided to join AMD in offering 64 bit x86-compatible processors as well and their marketing name is called "EMT64". Currently, all CSG lab computers are 64 bit, though many TA, RA, and Faculty machines remain 32 bit.


What do "x86" and "x86_64" mean?

In short, "x86" => 32-bit, "x86_64" => 64-bit.

"x86" and "x86_64" are instructions sets, the low-level set of instructions that a particular processor understands. x86 is the "standard" Intel 32-bit instruction set used by Intel, AMD, Transmeta, Via, and several other processor vendors. x86_64 is AMD's (and now Intel's) set of extensions to the x86 instruction set. The extensions give the standard x86 instruction set 64-bit capabilities, while not sacrificing backwards compatibility with the de facto x86 instruction set.


How do I determine if the machine is 32 or 64 bit?

The command uname -p will tell you the processor type of a machine. On a 64-bit machine it will output x86_64. On a 32-bit machine, it will likely output i686; though it may output i386, i486 or i586.

Why are the AMD64/EMT64 processors better than standard 32-bit AMD/Intel processors?

Following are a few of the reasons:


Can I run 32-bit applications on the AMD64/EMT64 machines? How about 64-bit applications on the 32-bit machines?

32-bit applications on 64-bit (AMD64/EMT64) machines can be run if the following are satisfied:

64-bit (AMD64) applications on 32-bit machines can never be run. The 32-bit processors simply don't have the capabilities.


What are the technical limits imposed by the Linux kernel, the AMD64 processor, and the RHEL load?

See /usr/share/doc/kernel-doc-*/Documentation/x86_64/mm.txt on any AMD64 Linux machine for more details:


How to I compile 32/64 -bit applications on 32/64 -bit processors using gcc?

There are four seemingly possible combinations:


How is runtime library loading handled? Where are the 32/64 -bit libraries located?

Runtime library loading, commonly referred to as dynamic linking, gives a program the ability to load a library at runtime, rather than at compile-time. The dlopen(), dlclose(), etc., family of C-language calls are used in this process. The issue on the AMD64/EMT64 machines is that both 32-bit and 64-bit libraries can be loaded by the dynamic linking loader. For this reason, a few common-sense best practices should be followed:


How do I know if a program or library is 32-bit or 64-bit?

The "file" command can be used to find out if a program or library is 32-bit or 64-bit. See "man file" for more information.


Example: A sample compilation/run of a simple "helloworld" program.

First, we have some source code

[joeuser@l-lnx133]$ ls -l
total 8
-rw-r--r--    1 joeuser   csg            75 Apr 30 10:07 helloworld.c

[joeuser@l-lnx133]$ cat helloworld.c
#include 
                                                                                                                                                                                    
int main ()
{
        printf("Hello World!\n");
        return 0;
}
We can see that we're on an AMD64/EMT64 machine
[joeuser@l-lnx133]$ uname -a
Linux l-lnx133.divms.uiowa.edu 2.4.21-9.EL #1 Thu Jan 8 16:58:25 EST 2004 x86_64 x86_64 x86_64 GNU/Linux
Next, we build 32-bit and 64-bit versions of the program, both statically and dynamically. Use the compile option -Wall to turn on all warnings.
[joeuser@l-lnx133]$ gcc -Wall helloworld.c -o helloworld-64-dynamic

[joeuser@l-lnx133]$ gcc -Wall -static helloworld.c -o helloworld-64-static

[joeuser@l-lnx133]$ gcc -Wall -m32 helloworld.c -o helloworld-32-dynamic

[joeuser@l-lnx133]$ gcc -Wall -m32 -static helloworld.c -o helloworld-32-static
As expected, the executable programs are of different sizes, with the statically compiled executables being significantly larger
[joeuser@l-lnx133]$ ls -l
total 928
-rwxr-xr-x    1 joeuser   csg          4703 Apr 30 10:47 helloworld-32-dynamic
-rwxr-xr-x    1 joeuser   csg        412373 Apr 30 10:47 helloworld-32-static
-rwxr-xr-x    1 joeuser   csg          6828 Apr 30 10:46 helloworld-64-dynamic
-rwxr-xr-x    1 joeuser   csg        487617 Apr 30 10:46 helloworld-64-static
-rw-r--r--    1 joeuser   csg            75 Apr 30 10:07 helloworld.c
The "file" command verifies that our compilations created the executables as we had intended
[joeuser@l-lnx133]$ file helloworld-32-dynamic
helloworld-32-dynamic: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), not stripped

[joeuser@l-lnx133]$ file helloworld-32-static
helloworld-32-static: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, statically linked, not stripped

[joeuser@l-lnx133]$ file helloworld-64-dynamic
helloworld-64-dynamic: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), not stripped

[joeuser@l-lnx133]$ file helloworld-64-static
helloworld-64-static: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.0, statically linked, not stripped
Finally, we run each of the executables to verify that they all run exactly the same
[joeuser@l-lnx133]$ ./helloworld-32-dynamic
Hello World!

[joeuser@l-lnx133]$ ./helloworld-32-static
Hello World!

[joeuser@l-lnx133]$ ./helloworld-64-dynamic
Hello World!

[joeuser@l-lnx133]$ ./helloworld-64-static
Hello World!
What should happen if we were to try to run either of the 64-bit executables on a 32-bit machine?
[joeuser@a-lnx000]$ uname -a
Linux a-lnx000.divms.uiowa.edu 2.4.21-9.0.3.ELsmp #1 SMP Tue Apr 20 19:49:13 EDT 2004 i686 i686 i386 GNU/Linux

[joeuser@a-lnx000]$ ls -l
total 928
-rwxr-xr-x    1 joeuser   csg          4703 Apr 30 10:47 helloworld-32-dynamic
-rwxr-xr-x    1 joeuser   csg        412373 Apr 30 10:47 helloworld-32-static
-rwxr-xr-x    1 joeuser   csg          6828 Apr 30 10:46 helloworld-64-dynamic
-rwxr-xr-x    1 joeuser   csg        487617 Apr 30 10:46 helloworld-64-static
-rw-r--r--    1 joeuser   csg            75 Apr 30 10:07 helloworld.c

[joeuser@a-lnx000]$ ./helloworld-32-dynamic
Hello World!

[joeuser@a-lnx000]$ ./helloworld-32-static
Hello World!

[joeuser@a-lnx000]$ ./helloworld-64-dynamic
bash: ./helloworld-64-dynamic: cannot execute binary file

[joeuser@a-lnx000]$ ./helloworld-64-static
bash: ./helloworld-64-static: cannot execute binary file
As expected, 64-bit executables will not run on 32-bit machines




Where can I go for more information about C?

  1. The website http://c-faq.com has a collection of frequently asked questions. The website http://gcc.gnu.org/faq.html has a collection of frequently asked questions for GCC.
  2. Most C functions have a man page (short for manual page) that can be viewed by typing man 3 functionname. For example, man 3 printf will give you information about the printf family of functions.
  3. If you need a reference for gcc's many options, you can read the man page for gcc by typing man gcc.
  4. Your TA or instructor. CSG is not a resource for debugging your code, however we do maintain the compilers and computing environment. Maintenance issues of the compiler or envornment (like the compiler won't compile the hello world program above) are valid questions.


Are there any commercial compilers available like Intel?

  1. The CSG maintains Intel Compilers in additions to the GNU compilers. For more information on using the Intel compilers, click here.