Mailinglist Archive: opensuse (5130 mails)

< Previous Next >
Re: [SLE] SUSE Linux 10.1 - 32-bit or 64-bit
  • From: Jerry Feldman <gaf@xxxxxxx>
  • Date: Fri, 19 May 2006 10:29:31 -0400
  • Message-id: <200605191029.31724.gaf@xxxxxxx>
On Friday 19 May 2006 9:33 am, Bryan J. Smith wrote:
> On Fri, 2006-05-19 at 09:01 -0400, Jerry Feldman wrote:
> > Actually, the x86_64 bit version of an application is built for 64-bit
> > virtual. The 48-bit/52-bit PAE is applicable when talking about the
> > OS's virtual memory manager, paging, and TLBs. An application built for
> > x86_64 (or Alpha or IA64) will have a full 64-bit virtual memory
> > address space
> That's the standard programmer line.
> But the binary is very much built _explicitly_ for 48-bit/52-bit PAE.
> We don't know if they will run if and when AMD implements a _true_
> "flat" 64-bit mode. If you read the fine print in AMD's own manual, it
> doesn't exist yet.
Again, the binaries built by the compiler use a flat 64-bit model. Remember,
that the binaries are built for virtual memory and they have a full 64-bit
memory model. The general purpose register set contains 16 64-bit registers
that are used for both data and for addresses. The VM provides the
appropriate mapping between the virtual address and the physical address.
Additionally, the binaries produced by the compiler are relocatable and
contain things like relocations. The linker uses these relocations along
with symbol tables to resolve link-time addresses, and produces a binary
containing additional relocations. The loader then recsolves these
relocations when loading a program. (Actually, the loader does a lot of
mapping since, in general, only needed pages are mapped in from the
executable. In general, only the OS needs to know specifically about the
physical memory. The running binary (in most cases) does not really pay
attention to the 48-bit/52-bit PAE model.
Additionally, the Alpha had 32 64-bit general purpose registers, and a
program have full 64-bit virtual addressability even though the physical
addressing was limited to 48-bits or less. But, virtual memory addresses
must be in canonical form.

> So there's no guarantee the binaries will be compatible. That's why I
> differentiate.
If a binary is explicitly built for features of a specific chip, it probably
will not be compatible. This has always been an issue. In general, when
building an application (or an OS) you build it for the target deployment.
In the case of x86-64 Linux distros, you build for the generic x86-64, not
to include specific AMD or Intel extensions.

> > as well as access to the full 64-bit registers.
> Yes, non-address registers are 64-bit.
There are 16 General Purpose registers that can contain either data or
addresses. The program counter is also 64-bits.

> There's a huge difference between what the "programmer" sees and what
> the "system programmer/organization" actually does, _including_ the
> resulting object code itself. ;->
This is true. The programmer does not concern himself with the specific
memory models. The system programmer may be concerned with the underlying
hardware. The application programmer sees a full 64-bit virtual
environment, especially if he/she is using a high level language (including
Jerry Feldman <gaf@xxxxxxx>
Boston Linux and Unix user group PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

< Previous Next >
Follow Ups