Why are still not at 64 bits [was Can't figure out Firefox Plugin Requirement ]

[Jon 'maddog' Hall]

> 
>   Binary: My understanding is that a 32-bit binary can be run under a
> 64-bit kernel, but you need a 32-bit environment to do so.  So any
> libraries the binary depends on also need to be built (for x86-32) and
> installed in parallel with their x86-64 counterparts.  I could be
> wrong on this; I haven't verified the information's authenticity, and
> I certainly haven't tried it.
> 
In theory this is true.

Assuming that the instruction set of the 64-bit processor supports the
instruction set of the 32-bit processor, or has a mode that it can enter
when it does a context switch that is completely compatible, then this
can be done.

You "simply" make sure that all programs are loaded into a virtual space
that is in the lower 32 bits of virtual address space.  The 32-bit
libraries have to be written to maintain the 32-bit interfaces, and
supply the 64-bit addresses to the kernel, OR the kernel has
modes/interfaces to accept both 32 and 64 bit addresses.

The bigger problem is with currently stored data and current programming
languages.

A very popular programming language in Unix did not define what size an
"int" was very well.  It kind of wobbled and said that it was "the
natural size" or something like that.  It also did not specify what
endianism the program should use. This was done so the compiler could
make decisions to get good integer performance.  So if I plopped down an
array of "ints" on the disk, how big are they REALLY?  And what endian
format were they when I read them?  Worse yet, if I plop it down with a
32-bit machine and try to read it with a 64-bit machine, what am I
getting?  Changes to this language in relatively recent years have made
this easier to control, but there is a LOT of legacy code out there that
does not change so well*.  Now there is a lot of legacy data.

I actually had a talk with Dennis Ritchie at a conference one time,
telling him about the problem, and suggesting a good solution.  He told
me to tell Steve Johnson, who was maintaining the AT&T compilers then,
as Dennis had moved on.  I told Steve, but nothing ever came of it until
MUCH later when issues forced it.

Now if you used programming language that defines this very well, or a
database engine to store and receive your data, with its paranoid data
dictionary making you define everything about the data (size, endianism,
etc., etc.) or you have network engineers defining your interfaces so
they know what type of system you are coming from, what type you are
going to, and what type of "network neutral data" you are going to have,
then everything is peachy.

Unfortunately, as Ben has noted, there are crappy programmers out there
in the world, and tons of legacy, binary-only software.  We no longer
even know what language they were written in, much less have the sources
so we can change them.  Heck probably a good percentage of those
programs the people don't even know what the program does, they just
run them.**

In 1989 as we were trying to create a version of Ultrix that ran on
MIPS.  "Most UNIX systems" (AIX, HP/UX, SunOS/Solaris) were big-endian.

Ultrix was little-endian.  So was SCO, but who cared about them, because
they were running on that slow, crappy Intel processor.

But we were trying to become "compatible" with the rest of the industry,
so we created a kernel that could either use big endian or little-endian
applications at the same time.  Just a matter of engineering and code.

But most of our customers had tons of little-endian data.  And we
realized that if we started down this path we would have customers
buying big-endian applications to treat little-endian data.

So we never released the functionality.

maddog

*Do not even get me started on "Unions" in "C", "Equivalence" in
Fortran, and "Linkage Sections" in Cobol.  I get really ugly fast.

**If you do not believe this statement, I can tell you HOURs of
examples. Maybe I will do that tonight at Martha's....but it always
makes me sooooo depressed.

***There are no statements above that relate to this footnote, but this
is simply a warning not to even SAY THE WORD "Itanium" to me.