Transition from 32 to 64 bit

Transition from 32 to 64 bit

[Bill Davis]

I have a large program written in Ada which currently runs on a 32 bit MIPS machine.  I have been requested to move this software to a 64 bit SGI machine.  We are running Verdix compilers on both machines.  I am having trouble because on the MIPS the float type is 32 bits and the long_float is 64 bits.  On the SGI machine the float is 64 bits and the short_float is 32 bits.  Is there any way to get this software running without actually changing all the floats to short_floats and the long_floats to floats 
in the source code.  If anyone has any suggestions, I would like to hear them.  Thanks.

Bill Davis

Re: Transition from 32 to 64 bit

[Robert I. Eachus]

In article <1994Sep20.160716.25347@relay.nswc.navy.mil> wbdavis@shooter.nswc.navy.mil (Bill Davis) writes:

  >    I have a large program written in Ada which currently runs on a
  > 32 bit MIPS machine.  I have been requested to move this software
  > to a 64 bit SGI machine.  We are running Verdix compilers on both
  > machines.  I am having trouble because on the MIPS the float type
  > is 32 bits and the long_float is 64 bits.  On the SGI machine the
  > float is 64 bits and the short_float is 32 bits.  Is there any way
  > to get this software running without actually changing all the
  > floats to short_floats and the long_floats to floats in the source
  > code.  If anyone has any suggestions, I would like to hear them.

    Okay:

      1) Use a different compiler.

      2) Create a package that defines:

         type Long_Float is new Standard.Float;
         type Float is new Standard.Short_Float;

         and in every library unit that uses Float or Long_Float put
         in a with clause and renames of the types (so they will hide
         the types from Standard).

      3) Get your compiler vendor to provide you with an alternate
         package STANDARD.  (Not as silly as it sounds, with many
         compilers this is a reasonable option.

      4) Modify the source to use, say Float_6 and Float_14, declared
         in terms of the actual required precision.  Then the port
         becomes easy, and no source changes are required.

    The last solution is, of course, the one taught to all Ada
programmers, so I assume that you are aware of it (and that someone
else wrote the offending software).  It may not seem like an
astonishing revelation that software written non-portably is not
portable, but there are a lot of managers out there who still haven't
figured it out.

    Since confession is good for the soul, I should point out that on
the ADAR project, where portablity is job one, everyone has made the
mistake of using Integer or Float in inappropriate places at one time
or another.  But we treat such occurances as serious bugs.  (There are
some places where you must use the standard types, and others where
they are used to match other standards, so there are places where
Integer and Float are used.)

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Transition from 32 to 64 bit

[Robert Dewar]

I don't often disagree with Norm, but I don't like his use of Float_6
and Float_15. This is reminsent of the PL/1 style in which 32 bit integers
were hard coded into all programs in the name of portability.

If you choose to define your own types, then PLEASE don't just pick up
the hardware parameters of the machine you are on, because that decreases
portability rather than increases it.

If you have done a careful analysis that 6 and 15 digis of precision are
indeed exactly what you need, then fine, but I BET that you have not made
such an analysis.

In fact, better advice would be to name the two types Single and DOuble,
and define them as new Short_Float and new Long_Float respectively. This
will lead to the right choices on pretty much all machines, and you canm
easily change them if you are on a nasty compiler that does not follow
the relevant uniformity recommendation (that short should be single
precision, long, double precision, and Float itself chosen as the more
efficient of these two formats).

The trouble with 6 and 15 is that it causes trouble on some machines.

For example, suppose your compiler provides only 6 and 14. Then you will
have to perform a very careful analysis of whether you can run at all on
that machine, because with Norm's approach you imply that you have carefully
analyzed things and determined that 15 is the minimum precision available.
If that's the case, fine, if not, please don't pretend!

Similarly, suppose your compiler provides 6, 14 and a special very slow
software format with digits 64. Do you really want to imply that you
demand the digits 64 type because the digits 14 type is inadeqaute.

This business of using supposedly portable features to build in 
non-portability is common. Consider:

   type x is range -2**31 .. +2**31-1;


Such type declarations are not uncommon, and are the frequent product of
people who are deathly afraid of using type Integer directly. When I read
such a type declaration I very much doubt that this is really the requird
range, instead I am almost sure that it is merely copied from the hardware.
But I don't know for sure.

Consequently when I try to port that application to a 32 bit ones complement
implementation (or an implementation, like the old rational machines, that
used the largest negative number as an undefined value), I don't know 
whether I can safely adjust the low bound by 1.

The proper solution for integer is to use the actual range your application
requires. Sometimes this generates rafts of junk software checks, so in
that case, the nice solution is:

    type hidden_type_not_used is <range-actually-needed>;

    type actual_type_to_use is range hidden_type_not_used'first

				  .. hidden_type_not_used'last;


In Ada, you can use the Base attribute to write this neatly.

Oops, I should have written 'base'last and 'base'first in the above
example, and what I meant in Ada 9X is that you can use


type actual_type_to_use is new hidden_type_not_used'base

which is a little neater. These give you a type that has the range you need
but the range is increased to the next efficient hardware type.

Incidentally, the use of Integer is not necessarily inappropriate if when
you write Integer you mean (some efficient type suitable for indexing
arrays, and I am quite willing to be limited by whatever the machine provides
for efficient array indexing).

Re: Transition from 32 to 64 bit

[Robert Dewar]

There are definitely machines in which double precision float (64 bits) is
much more efficient than single precision float (32 bits). This can arise
from two sources. First, you can have problems with checks (e.g. on the
x86 with 64-bit precision mode set, the checks are free for 64-bit but
require expensive store instructions for 32-bit). The permissions in 
Ada 9X for going outside the range of unconstrained floating-point types
help a lot in eliminating this annoying glitch.

Secondly there are machines where all machine arithmetic is always done in
64-bit (notably the RS6000, but NOT the power PC). On such machines you may
well find that 32-bit fpt is slower.

That's why incidentally the uniformity recommendation is that short_float
should be 32 bits (or whatever makes sense for single precision), long_float
should be 64 bits (or whatever makes sense for double precision), and
float should be whichever of these two types is more efficient in practice.