Re: OpenVMS Still Only 32-Bit Addresses!?

John Wallace <johnwallace4@xxxxxxxxxxx> wrote:

(snip, someone wrote)

"A 64bit number cruncher is pretty useless without enough RAM under
the hood."

Don't think so right back at you.

You have your definition of 64bit number cruncher and the
rest of the world has theirs.

It's perfectly possible to have a problem that requires 64bit
precision without needing massive datasets (ie bigger than 32bit
address space, or whatever maximum amount the OS allows the app to
use). In fact for a long time the 64bit address space wasn't even
practical. Even now, with 64bit-addressable processors the industry
default, not many boxes actually need more than 32bits worth of
address space of physical memory (that's probably less true this year
than it was before Windows Vista).

Yes. The previous post, as I understood it, was trying to indicate
that 64 bit virtual address would be useful with 4GB or less
physical memory. The comments, by me and others, indicate that
often isn't true. If you can get by with a 32 bit virtual address,
then that is fine.

The number of applications needing >32bit virtual or physical address
space was and is relatively small in comparison with the number that
may benefit from >32bit precision. E.g. how big is C "long long" in
your world? Does "long long" arithmetic appear (to application
programmers) to work on a 32bit CPU with a 32bit OS?

It isn't hard to do 64 bit add and subtract, and even 32 bit
multiply with a 64 bit product on 32 bit hardware. Just a little
harder to do 64 bit product. If you don't do it so often,
divide by a 64 bit dividend isn't so hard, either.

You may be familiar with UNIX's time_t, which is now 64bits.
Calculations using it (or any similar 64bit quantity) don't need a
64bit virtual address space, but they do benefit from more than 32 bit
arithmetic.

Fortunately time_t is rarely in the inner loop of a number
crunching applications.

There are still lots of apps where 64bits is too much wasted memory
for a default int though; why waste half your valuable cache?

D.E.Knuth has a web site (I believe that is where it is) complaining
about the wast of 64 bit addresses (also in cache) where they
are not needed.

(snip on ILP notation)

You can find further discussions on how this relates to VMS in the VMS
Calling Standard docs. As has been pointed out, user programs on VMS
miraculously appear to use the ILP32 model even though the underlying
hardware operates in 64bit address mode. (Stuff that works closer to
the hardware may well *have* to know about these distinctions; normal
user apps don't).

If I remember rightly, Tru64 (DEC OSF/1 as it then was) and Solaris
both use(d) the LP64 model. 64bit Linux on AMD64 also uses LP64; "int"
remains 32bits by default.

I do remember 64 bit (long) on the early Alpha systems, before
(long long) existed. It broke a lot of code, especially TCP/IP,
that most later changed to 32 bit (long) and 64 bit (long long).

-- glen
.

Relevant Pages

  • Re: Drag it to the trash...
    ... in hardware to do all that. ... is the registry journalled and is XP a journaling file system? ... Neither of these was in any way an innovation. ...
    (comp.sys.mac.advocacy)
  • Re: more than 16 significant figures
    ... > one non-significant bit results in a value with two non-significant ... > loss of any extended precision available to the hardware. ...
    (comp.lang.java.programmer)
  • Re: more than 16 significant figures
    ... >> Java specifies IEEE 754-1985 representation for floating point. ... It specifies 53 bits of precision for doubles, ... one non-significant bit results in a value with two non-significant ... loss of any extended precision available to the hardware. ...
    (comp.lang.java.programmer)
  • Re: Rounding issue
    ... Perl does not provide BCD natively (Binary Coded Decimals; ... important most hardware does not support BCD arithmetic, ... round and which precision to expect and were warned sternly not to hunt ...
    (comp.lang.perl.misc)
  • Re: BigNum -- Floating Point
    ... <snip English description of method> ... Mixed-base floating point, perhaps? ... use a big amount of space to store it. ... Then either you take the loss of precision like a man; ...
    (comp.programming)