Mailinglist Archive: opensuse (5130 mails)

< Previous Next >
Re: [SLE] SUSE Linux 10.1 - 32-bit or 64-bit
  • From: "Bryan J. Smith" <b.j.smith@xxxxxxxx>
  • Date: Sat, 20 May 2006 10:32:00 -0400
  • Message-id: <1148135520.3616.10.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
On Fri, 2006-05-19 at 11:23 -0400, Jerry Feldman wrote:
> There is never that guarantee, but there is always some work to provide a
> certain amount of binary compatibility. Neither AMD not Intel is going to
> extend this architecture in such a manner as to render existing code
> unusable.

Yes and no.

Again, understand there is a _hard_ 48-bit/256TiB physical addressing
limitation with the current 48-bit pointers and 52-bit PAE addressing.
256TiB is _not_ a lot of memory in 5 years. So to overcome the
48-bit/256TiB limitation, AMD has to _break_ i486 TLB compatibility. So
_any_ kernel that implements such a memory model that _breaks_ the
48-bit/52-bit PAE model that was designed to _explicitly_ support
32-bit/36-bit PAE programs.

So, YES they will _break_ compatibility on the same OS!

The solution is to use virtualization. The architecture will support
greater addressing than 48-bit/256TiB in this new mode, which is what
the "supervisory" OS will use. But then the architecture can support
"instances" of 48-bit/52-bit PAE, 32-bit/36-bit PAE, etc..., which will
run 48-bit/52-bit PAE, 32-bit/36-bit PAE, etc... OSes underneath. In
fact, Microsoft's _core_ compatibility effort is going to leverage this
in a future Vista release.

So, no they won't break compatibility -- using virtualization.

> The ABI is defined through a series of calling standards. ABIs can get
> complicated, as you mention. Before we had defined ABIs, it was very
> difficult for a COBOL program to call a FORTRAN library. For the most part,
> programmers had to write bridge code in assembler. The ABI not only goes
> into how to call a procedure, but also how symbols are defined. In C++, it
> is important that the symbols are all mangled in the same way. This is
> extremely important with dynamic shared objects (.so). it would be
> interesting if GCC used a different mangling algorithm in their compilers
> than Intel does in theirs.

Object code for x86-64 is flat 48-bit pointers then used in a 52-bit PAE

Object code for i486/586/686 is segmented/virtual 48-bit pointers used
in a flat 32-bit or extended 36-bit PAE model.

The pointers are _not_ compatible in calling each other.

The only compatibility is that the OS, controlling the 52-bit PAE model,
can run 36-bit PAE extended and 32-bit flat applications, as well as
newer 52-bit PAE programs. This is because addressing is always 48-bit,
even if not normalized the same way.

To break the "hard" 48-bit/256TiB addressing limitation, _none_ of these
programs would run under it. That's where virtualization is going to
solve the problem.

Bryan J. Smith Professional, technical annoyance
Americans don't get upset because citizens in some foreign
nations can burn the American flag -- Americans get upset
because citizens in those same nations can't burn their own

< Previous Next >