At 10:26 07.05.1997 -0700, Gavin wrote:
>John asks:
(...)
>> Did I miss out on something here?  I was under the impression that
>> a) the PA-8000 series chips are 32-bit and not 64-bit, and
(...)
>
>The PA-8000 chips implement PA-RISC 2.0, which uses 96bit virtual
>addressing and 64bit physical and addressing and a full 64bit data
>path.  All registers in the CPU are 64bits wide.  It doesn't get
>any more "64 bit" than this.

[lots of excellent points from Gavin's post snipped for brevity here]

The whole thread reminds me of a frequent misunderstanding that the
current MPE/iX would be a "32bit O/S" whereas all the miraculous new
Unixes (or even NTs) would become "full 64bit" later this afternoon
(oops, I should not slip into cynism here ;-)

MPE/iX since its very beginning uses PA RISC 1.x processors which
essentially have 32bit registers, data paths etc. but offer virtual
addressing using a space-id/offset scheme that goes beyond 32-bit
range (exact address range depends on implemented number of bits in
the space-id which is somewhere between 16 and 24 bits, I believe).

MPE/iX utilizes this virtual address space extensively e.g. a single
process has one or more spaces for code (program and/or XL libraries),
one space for private data (globals of program, XL modules, NM stack,
CM stack, NM heap etc) and two spaces for shared OS resources like
system tables. Most file types are handled as mapped files (even if
user program does not open for mapped access) and typically reside
in their own space-id's, too.

In a nutshell, MPE/iX uses the PA-RISC architecture very efficiently
and elegantly and is not very much constrained by the limitation of
32-bit LINEAR addressing (inside one space-id). Yes, there are certain
cases where 32-bit LINEAR addressing is limiting e.g. flat files of
more than 4 GB size. But overall the system does not suffer "too much"
from the 32-bit hardware restriction (in my opinion) and thus would
possibly not gain that much benefit from moving to 64-bit that might
be expected when following all the 64bit marketing hype of these days.

There are other PA-RISC based operating systems (which I am probably
not supposed to name explicitly here, even if I emphasize that this is
my very own very personal opinion and far from "the truth") available
that utilitze PA-RISC features -ahem- differently (wow, that was pretty
diplomatic) by squeezing code, data, shared libs, shared memory, user
mapped files etc. into one single space-id (and leave another for the
kernel mode if I remember correctly). These implementations seem to be
much more affected by a 32-bit LINEAR addressing limitation of PA-RISC
versions 1.x and might benefit much more from PA-RISC 2.0 addressing
space enhancements (in my opinion).

So much regarding 32-bit versus 64-bit from my point of view.

By the way, things are slightly more complex as 4 GB address spaces are
subdivided into 1 GB quads but that does not affect the general concept
explained above.

Another topic that I did not touch, that is related to PA-RISC 2.0 but
not that much to 32-bit vs 64-bit is the capability of the new processors
to execute more simple instructions in parallel (e.g. multiple independent
16bit integer calculations in one step, which is very useful in multimedia
applications, graphics or audio processing) if the compiler arranged the
instruction stream carefully. This feature might or might not provide some
performance benefits in commercial applications. Mileage my vary.

"PA-RISC 2.0 Architecture" by Gerry Kane is available for reading details.

Kindest regards,

Lars (did all the 64bit marketing hype really make me that angry?) ;-)

PS: Would a 64-bit MPE be called MPE/64 or MPE/XXL ??  :-)