Bruce writes:
> I will point out that this scheme isn't quite as flexible as Gavin
> suggests. There is only a 32-bit space register, meaning that the OS can
> manage, at most, 2^32 - 1 processes.

They are architected as being between 32 and 64-bit space registers, with
only 32-bits being implemented in the current PA-8x00 chips.  Also, the
Space Register value is overlaid onto the top half of the 64-bit "offset"
portion of the address during GVA (Global Virtual Address) formation,
which means that only the "upper bits" of the space register value can
be used to specify the "space", as the "lower" bits are zero in order
for the offset part of the address to exceed 32-bits of effective
address.  This is where the HP-UX 11.0 16TB addressing limit comes from.
The lower ten bits of the space ID value are always zero, allowing an
effective 22-bit space, and 42-bit offset for virtual addresses (non-
privileged code actually never sees that space registers exist, and
can't tell that the world isn't a flat 64-bit address space).

So you only get 2^22 - 1 processes (more or less) today.  If you needed
more processes you could change the 22/10 split to trade off offset bits
for more space id bits, and if you need more than 16TB of address space
per process then you can go the other way and give up space ID bits to
increase the maximum "offset".  When you run out of space ID bits, your
next generation of PA-2.0 chips will need to implement more than 32 of
the possible 64 space ID bits.  In a full implementation you will have
a 64-bit space-id and a 64 bit offset which share 32 bits in common.
You could then have a full 2^32 - 1 spaces each having access to a full
2^64 - 1 (more or less) offset range, for a total effective 96-bit
virtual address range.

This ought to be enough to last for a while I would think.

> I distinctly remember being in a technical roundtable session at the
> Interex (then HPIUG) conference in Edinburgh in 1983. They were
> discussing the 32-bit address space that Vision was going to have, and
> announced that 4GB would be enough for the foreseeable future. I predict
> 16TB is going to seem as laughably small in 2015 as it seems laughably
> large now.

But as noted above even the current chips will support more than 16TB of
address space, and programs written today for the 64-bit architecture
will run unchanged on a full 96-bit implementation.

> >If MPE ever becomes a real 64-bit OS, then it will be able to take advantage
> >or the HP-UX way of doing things (Note that becoming 64-bit and running on
> >IA-64 are two *unrelated* issues).
>
> Not completely, since the MPE lab is a lot more reluctant to fork OS
> development than the Unix folks. HP 3000s are expected to last five years
> or more, meaning that forking the OS to allow a true 64-bit MPE would
> leave out all the PA-RISC 1.x systems manufactured in the last five
> years. The timeframe for the second-generation IA-64 chip is just about
> the earliest that HP could reasonably cut off all the 1.x people from new
> OS development.

I said "unrelated" because current PA-RISC chips support both 32-bit and
64-bit programs and so apparently will IA-64 chips, meaning that a move
to support true 64-bit apps could happen on today's PA-2.0 systems or
could wait until after the move to IA-64, or might never happen.  Current
HP-UX supports simultaneous execution of 32-bit (PA-RISC 1.x style)
programs and newer 64-bit (PA-RISC 2.0 style) programs, and HP-UX on
IA-64 will do the same.

Also, HP-UX is currently "singe source" for PA-RISC 1.x, PA-RISC 2.0 narrow,
PA-RISC 2.0 wide (64-bit), *and* IA-64 (according to HP), so "forking"
seems to no longer be an issue at least for HP-UX.  A reasonable amount of
cleverness ought to allow MPE to do the same if they are so inclined.

G.