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
model.

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
mailto:b.j.smith@xxxxxxxx http://thebs413.blogspot.com
-----------------------------------------------------------
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 >