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 11:23:32 -0400
  • Message-id: <200605191123.32628.gaf@xxxxxxx>
On Friday 19 May 2006 10:57 am, Bryan J. Smith wrote:
> From the programmer's standpoint, but not the object code from what I've
> seen. Or let me re-phrase that, there is no guarantee that the object
> code that runs on 52-bit PAE will work on future AMD/Intel "flat 64-bit"
> platforms.
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.

> Again, from the programmer's standpoint -- Application Programmer
> Interface (API). I'm not talking about programmer, I'm talking about
> Application Binary Interface (ABI) compatibility. Whole different
> ballgame!

> And you've really over-simplified the compatibility here. It is _not_
> easy to create a 52-bit PAE to 32-bit/36-bit PAE translation so object
> code of each can link against the other.

> C is API.
> Object code is ABI.
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.

--
Jerry Feldman <gaf@xxxxxxx>
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

< Previous Next >
Follow Ups