32-bit stuff on an x86-64 box???

[Lennart Sorensen]

On Fri, Jun 10, 2005 at 08:11:22PM -0400, Walter Dnes wrote:
> On Thu, Jun 09, 2005 at 10:40:28PM -0400, William Park wrote
>   A 64-bit cpu running in 32-bit compatability mode makes as much sense
> as buying a Mac, and using an emulator to run nothing but Windows apps.
> Save yourself some money, and buy the real thing.

An AMD 64bit cpu runs x86 32bit code faster than anything else natively
(except for a few odd SSE cases where a P4 wins).  it makes perfectly
good sense, unless you think a Sempron is a good cpu to buy just because
you don't use 64bit code yet.  The only athlon available now, is 64bit,
but runs faster at 32bit than any other athlon ever did, so why not buy
the 64bit one.  It's cheaper than a P4 that only runs 32bit code too,
and faster than that P4.

Makes perfect sense if you have 32bit code to run and want the fastest
system to run it.

>   If you can compile most or all of your apps to run in 64-bit mode,
> then you can expect genuine improvement in cpu-constrained apps.  Any
> compile-from-source distro (Gentoo, LFS, Slack, etc) should benefit.
> See the article at http://www.devx.com/amd/Article/16018 for details.
> To summarize...
> 
>   - general-purpose registers (GPRs) increased from 8 in x86-32 to 16
>     and, of course, their size is now 64 bits

Certainly a benefit to some programs.  Too bad you also gain the memory
hit from having all pointers twice as large.  For pointer heavy code
that can actually be significant although with the memory bandwidth of
the A64 it's not a big deal.

>   - 128-bit XMM registers (used for Streaming SIMD instructions)
>     increased from 8 to 16.
> 
>   One big complaint about X86/32bit cpus has been the limited number of
> registers.  The extra registers on the AMD64 reduce the need for memory
> accesses, and a compiler that knows about them can speed up calculations
> significantly.
> 
>   Now let's talk about 32-bit stuff on an x86-64 box (which is why I
> changed the thread subject).  The AMD64 has 32-bit compatability in
> 64-bit userland.  Is anybody running in 64-bit mode and have binary-only
> stuff like Macromedia/Adobe's Schlockwave-Trash, Sun's Java, and
> OpenOffice (depends on Sun's Java) working in 64-bit userland?

I have seen 32bit vmware run on a 64bit system, with just 32bit
libraries that it requried installed.  Debian recomends a chroot to hold
the 32bit stuff so apt-get can manage a native 32bit install in the
chroot, while /etc/ld.so.conf can point to both the chroot and the main
system and most 32bit programs can then be run directly picking up the
right libs as needed.  Rather painless for most users really.

>   What about parts of *KERNEL MODE* code being 32-bits in a 64-bit
> environment?  I'm talking about nVidia's proprietary video-card drivers.
> And let's not forget nVidia's mother boards, which are often the base
> for AMD64 cpus.  Anybody got the motherboard's built-in video/sound/nic
> working whilst running the cpu in 64-bit mode?

Nvidia released 64bit versions of their drivers a long time ago (long
before ati even got around to releasing 64bit windows drivers).

forcedeth (reverse engineered driver) works fine.  It has source after
all.
Sound works fine in AC97 mode (alsa likes it) and never needed the
binary module.
Sata and ide works fine.
Video works using either 2D open source drivers in xfree86/x.org as on
32bit, and using 64bit proprietary drivers from nvidia which have been
around for at least a year now.

Lennart Sorensen
--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml