(Note: two sections herein: comments on 32/64 bits/POSIX, and the reply to the
 "why no non-priv access to freezing data")
 
Dan writes:
 
> I'm still looking forward to real usable 64-bit memory on MPE, too. Note
 
Hmmm... you stopped looking years ago...maybe you forgot?
 
> that although you can open a file long-mapped (with a 64-bit pointer), MPE
> apparently limits you to a file size of 2 gigabytes. Doesn't sound like 64
 
4 GB...years ago.
 
And, you're right: that's a 32-bit limit (well, a modern 32-bit limit,
compared to POSIX 2GB 32-bit limit...difference between unsigned and
signed 32-bit integers).
 
The key difference between PA-RISC's 64-bit architecture and other newer ones
is that there is no 64-bit integer arithmetic hardware.  This means that
in practice you are limited to having billion of separate address spaces,
each of which is limited to 4GB.  So, you have a total address space of
4GB * 4GB (16,000 terabytes bytes), but not as a single 64-bit flat
 address space.  That's one of the reasons that MPE
limits a file to 4GB.  HP-UX, being POSIX oriented limits you to 2GB.
 
Example of hardware limitation.  Let's say you got MPE/iX (or HP-UX) to give
you 8 GB of "contiguous" virtual address space, starting at $100.0.
(I.e.: addresses $100.00000000 through $101.ffffffff)
 
If you have $ffffffff in register R21, and $100 in Space Register SR1,
and attempt to fetch byte $101.$00000001 by doing:
 
        LDB 2 (1, 21), 9
 
it won't work.
 
You hoped that the arithmetic of adding 2 to unsigned $ffffffff would result
in the space ID of $101 being used (because of the carry) and the offset
of $1 (bottom 32 bits of result of $ffffffff + 2) ... but what happens is
that the result of $ffffffff + 2 doesn't affect the space register, so
the byte accessed is at $100.1.
 
That's the limitation that PA-RISC 8000 architecture (announced
a while back) addresses.  (I seem to recall that that will have 96 bit
virtual memory.)
 
> POSIX's API allows you to access files or memory of any desired size, easily
> beyond 2 gigabytes. See lseek(2), and keep in mind that off_t is
> architecture specific just like size_t is.
 
Been there, done that.
 
I just realized that, according to Dan's arguments, I can claim that
POSIX doesn't even support files bigger than 32KB!
(If I happen to have an architecture where off_t is 16 bits!)
 
In short, unless the POSIX "standard" says "off_t" *MUST* be at least 33
bits, then you cannot write a "POSIX compliant program" that is guaranteed
to be able to use files > 2GB.
 
A standard that says "off_t" may range from x bits to y bits on different
architectures (where x < y) is actually less useful than one that says
"off_t" must be x bits.  Why?  Portability is impaired.  You can more easily
write portable code if you *know* that the size of the types are fixed
across various architectures.  Ah, for int16, int32, int64 ... types that
mean something!
 
> POSIX was not so shortsighted as to not be able to see beyond 32 bits.
 
No, but cross-eyed enough to screw up anyway!
 
> >> Both methods given (the 'debug method' and the 'freeze' method) do not
> >> address the need to *programatically* do memory locking from within an
> >> application itself. Is there a way or isn't there a way to have an NM
> >> program do this on MPE?
> >Yes, PM required:
>
> Any non-priv modes? If not, any reason why?
 
Yes, two reasons I can think of:
 
   1) providing a non-priv method means documenting it ... which takes a
      lot of work, and testing ... for little payback.
      (It won't sell more machines, I hear the marketing people say)
 
   2) hubris? ... the theory is that letting users freeze data into
      memory would defeat the efforts of the memory manager / dispatcher...
      which presumably knows better than the programmer.
      Personally, I feel that in some cases the programmer does know better!
      (and, in others, MPE knows better)
 
--
Stan Sieler                                          [log in to unmask]
                                     http://www.allegro.com/sieler.html