If you are not lucky enough to have access to a 64-bit computer, you might be wondering about some of the implications of having a 32-bit environment alongside the 64-bit one. Read on.
Post a Comment
Member since:
2005-07-06
Member since:
---
Member since:---
Erm, well both of course. It means 64-bit integer registers, so the processor really is processing data in 64-bit chunks, which helps enormously for certain things (eg cryptography). But it also means a theoretical 64-bit memory address space, which would be measured in exabytes. In practice, the physical address space is much smaller (40 bits on AMD64), but that's still a vast expansion over 32-bit machines, allowing 1TB of physical memory.
Member since:
2005-07-06
i have an athalon64 system and i have gentoo installed on it twice on 2 different partitions... the 2 systems are virtually identical except one is full 64 bit and one is 32 bit... the only thing that differs between the 2 installations is the 32 bit install has some plugins not available for 64 bit.. that's it they both run gcc3.4.4, kde 3.4.1.... all apps are identical
now.. the first thing i noticed with the 64 bit system was the general speed of the gui..... very nice and snappy.... a bit faster then the 32 bit, but the second and most amazing thing was the substantial decrease in compile times...... I clocked it out to somewhere in the vacinity of 30-50% faster depending on the application that is being compiled
I was impressed
now i know much of this has to do with the utulization of the added registers in 64 bit but... wow
this is the first 64 bit machine i have build and... i'll never go back.
Member since:2005-07-06
but the second and most amazing thing was the substantial decrease in compile times...... I clocked it out to somewhere in the vacinity of 30-50% faster depending on the application that is being compiled
I experienced the same.Compiling firefox-1.0.6-r3 for eg didn't take as much time that it would normally on x86 (even a P4 3.0GHz).
this is the first 64 bit machine i have build and... i'll never go back.
Defenitely,would like to get my hands on one of those X2's.
Member since:
2005-07-06
Member since:
2005-07-08
A nifty trick is to install a 64-bit nix system and then build a similar 32-bit system rooted at a mountpoint on the native filesystem, /mnt/root32 for example. Then you can launch 32-bit apps in a 32-bit environment without rebooting. You can have a complete 64-bit desktop on display :0 and a 32-bit clone on :1 if you have nothing better to do with your memory.
Member since:
2005-07-07
...Then you can launch 32-bit apps in a 32-bit environment without rebooting
Or you could run (Open)Solaris, which doesn't require any of that kinda silliness. Solaris has been a 64bit OS for years (since approx 1997 iirc) and has always had the ability to run 32bit apps when the kernel is in 64bit mode. No chrooting required.
Regarding the article itself, the thing to note is that if you want to create a 64bit app or kernel module on any platform, you need to be very careful with your data handling and build commands. That point came through very clearly.
Member since:2005-07-06
Member since:
2005-07-06
64 bit CPUs don't all have 64 bit address busses. The 64 bit MIPS processors often have a 32 bit address. The processor in the PS2 (EmotionEngine) is that way. What makes the designated width of a CPU is how wide the arithmetic logic unit is.
For example, the Motorola 68000 had 32 bit wide general purpose registers, but the ALU was 16 bits wide. A 32 bit ADD took 2 machine cycles to complete. The 68000 was therefore a 16 bit CPU. The 68020 had a 32 bit ALU which could do that same 32 bit ADD in one machine cycle, so it was a 32 bit CPU.
The EE in the PS2 is a 64 bit CPU because the ALU is 64bits wide and can do a 64bit ADD in one machine cycle. When it forms addresses, the top 32 bits of 64 bit values are ignored. Only the lower 32 bits are used to address memory.
Member since:
2005-07-10
Member since:
---
Member since:
---
Developing 32 bit under a 64 bit OS is tricky.
What I say here is true for Fedora Core 2, but may have been fixed since then:
Almost every package that is available as both 32-bit and 64-bit has files which are either:
1. binary executables - they share the same path, so you don;t care which one runs
2. binary shared libraries - these use different paths and can coexist
3. config files/scripts - if these share the same path they will always be identical.
This means you can install the 32 bit package, then override it with the 64-bit version. both packages are stored at the same time since they use different architectures (x86 vs. x86-64 IIRC).
This breaks down with the gtk-devel, glib-devel and proably others. These have a gtk-config,glib-config scripts used by autoconf generated ./configure files.
The ./configure script uses these scripts to query the path of the gtk/glib libraries.
Unfortunately, these scripts break rule 3 above. gtk-config and glib-config share the same path in the RPM yet these scripts are different for 32 and 64 bits.
This made 32 bit development under a 64 bit OS less than transparent. You have to manually manage different version of these scripts and juggle between them to make 32 bit compiles happy.
The solution back then was a 32 bit chrooted env, which was mentioned above and was ridiculed by other, wrongly claiming Fedora doesn't need this.
so for 99% of the time a chrooted environment is not needed, but sometimes its the cleaner solution.
I hope FC3 or FC4 has solved this (haven't bothered to check since then).
