Re: Identification 32/64 bit Linux

On Friday 16 October 2009 13:37 in comp.os.linux.setup, somebody
identifying as Jacob wrote...

Thanks for the Answers, it seems, that I have 32 bit OS installed
everywhere. I just checked and noticed that my CentOs was´nt X86_64
version. I started a Download and will reinstall with this Image. I
will post the results in a couple of hours.

Just as a heads-up because other people have made that mistake in the
past, a 64-bit distribution for an x86-family processor will typically
be labeled "x86-64" or "AMD64" - the latter is the name originally
given to x86-64 since AMD were the first to implement a 64-bit
extension to the x86 architecture - but *never* "IA64". You may also
come across the designation "x64", and although this implies an x86-64
platform, "x64" is not an officially accepted designation, but merely a
misnomer by MICROS~1.

If you come across packages or /.iso/ files for IA64, then you should
know that these are explicitly for the Intel Itanium architecture,
which is not an x86-family platform. "IA32" on the other hand is the
name typically given to the subset of 32-bit processors within the x86
family, which in itself also includes 16-bit processors such as the
8086, 8088 and 80286.

The Itanium platform was given the designation "IA64" because it was
Intel's intention to have the Itaniums be the commercial successor of
the IA32 architecture, eventhough it's an entirely different platform.
The Itanium has an x86 compatibility mode, which emulates an IA32
processor in all of its modes - i.e. real mode, 16-/32-bit protected
mode and virtual 86 mode (which is a real mode emulation from within
protected mode) - but this compatibility with the IA32 is only
emulation and does not quite perform as well as a native IA32
processor. In fact, IA32 emulation on the Itanium is so slow that it's
not even being used by anyone, which has why Intel has contemplated -
and I don't know whether they've actually done it - simply removing the
IA32 compatibility mode from the Itanium platform for the development
of the Itanium 2.

On top of that, the Itanium was very expensive and therefore not quite
something the mainstream was waiting for. This is what prompted AMD to
start developing a 64-bit version of the IA32 which is still an
x86-family processor and which can run 32-bit applications natively -
i.e. without emulation - in a 64-bit environment. The press then
started calling this x86-based AMD 64-bit architecture "AMD64", and the
name was soon adopted by AMD itself as well.

Intel then realized that their Itanium was indeed not suited for prime
time use - both pricewise and performancewise - and also started
extending the x86/IA32 architecture to the 64-bit level, albeit that
their own implementation of it differed somewhat from that of AMD - for
one, the AMD64 architecture was designed as a ccNUMA unit, with the
memory controller built into the processor chip, so that on
motherboards with multiple processor sockets, each processor chip would
have its own memory controller and its own "local" memory banks, like
on higher-end servers and mainframes - and on top of that, the early
Intel x86-64 processors were actually incomplete, in that they were
primarily designed to be /used/ as 32-bit processors which were
(partially) capable of of 64-bit functionality.

In other words, Intel's first x86-64 processors were actually just a PR
thing to tell the world "Hey, we've got those too." Their next
generation of x86-64 processors however was a genuine and fully
functional x86-64 based upon a license of the AMD design, although they
didn't want to go the ccNUMA way as AMD had done up until the i7
generation was developed. Intel calls its implementation of
x86-64 "EM64T".

There are some differences still between AMD's x86-64 implementation and
the one from Intel, but these differences are now of the same technical
nature as the differences between a 32-bit Intel Pentium 4 and a 32-bit
AMD Athlon XP, i.e. they are just brand-specific differences which
require different optimizations of the code, but they are both
compatible with the generic x86-64 code of stock distribution kernels,
just as you could run an stock 32-bit distro kernel on either an Intel
Pentium II, Pentium III, Celeron or Pentium 4 versus an AMD K7, Athlon
or Athlon XP. Before Intel licensed AMD's 64-bit extension of the x86
architecture, this was not the case. Even generic "AMD64" code would
not properly run on an early Intel x86-64.

One of the important differences to note between x86-32 and x86-64
however is that although an x86-64 can run 32-bit code natively in a
64-bit environment, it cannot run 16-bit real mode code via VM86 while
running a 64-bit operating system. If it is used with a 32-bit
operating system, then the x86-64 has all the typical IA32 modes
available, i.e. real mode, 16-bit/32-bit protected mode and virtual x86
(or VM86) mode. This 32-bit mode is called "legacy mode".

When an x86-64 processor is used with a genuine 64-bit operating system
however, then it runs in so-called "long mode", which has a
32-bit "compatibility mode", allowing 32-bit code to run natively in
the 64-bit environment. This compatibility mode is not an actual mode
that the processor has to switch in and out of; it is simply an
environment 32-bit applications can run in without any modification of
the code. However, in "long mode", there is no "virtual x86" mode
anymore to run things like a DOS emulator in, although there exist of
course DOS emulators which emulate an actual real mode processor purely
in software; /dosemu/ for Linux for instance does that, even on a
32-bit processor.

The absence of 16-bit compatibility via virtual x86 mode is why a 64-bit
kernel must for instance use other means for switching the video card
into a different mode of operation. On 32-bit operating systems this
was simply done via a legacy real mode call to the video adapter's BIOS
from within virtual x86 mode. (VM86 differs from real mode in that the
pagetables are still active and that the entire VM86 session can be
multitasked by the protected mode kernel, although the multitasking of
processes /within/ the VM86 session is of course just as tedious as it
is in actual real mode, because, again, within the session itself,
there is no memory protection and no kernelspace/userspace difference.)

The above elaborate explanation is probably all superfluous, but I hope
it was at least informative and entertaining. :p

--
*Aragorn*
(registered GNU/Linux user #223157)
.

Relevant Pages

  • Re: Year of the Itanium
    ... Intel toasts Itanium's success by giving servers away ... Aptly dubbed "The Intel Itanium 2 Solution Challenge," the new program ... server and related services for up to 90 days for a gratis kit evaluation. ... If you're a software maker looking for volume sales, ...
    (comp.os.vms)
  • Re: IA64 and emulator performance
    ... Although I thought Intel had patented EPIC, ... The claim may be based in the fact that IA-64 ... However, Itanium proved to have minimal benefits for desktop CAD, ... People with supercomputing problems that fit really well onto Itanium, ...
    (comp.arch)
  • Re: OT: Intel Demos 48-Core Prototype Chip
    ... of Itanium updates makes me think Intel is treating Itanium like a ... So, by the time the next IA64 comes out, people are likely to yawn at ... a similar case could be made for Intel. ... Intel thought AMD would only make incremental changes to their ...
    (comp.os.vms)
  • Intel tips more details on Itanium roadmap
    ... the so-called Common System Interconnect will appear in both Itanium and Xeon server CPUs. ... Tukwilla, Intel's code name for a four-core Itanium processor due in 2008, will be the first to use CSI instead of a traditional Intel front-side bus to link to external components. ... The new Itanium CPU is expected to sample this year and will also use a form of simultaneous multi-threading expected to support two threads per core. ...
    (comp.os.vms)
  • Re: How Intel Can Save the Itanium!
    ... Itanium (End of Alpha sales was going to be in October 2006 but HP ... I had a very interesting 'phone call with Intel ... of those Merced systems were dual-processor. ... decide it wasn't worth the money. ...
    (comp.arch)