Re: VMS to Unix (was: Is there a Fortran to Ada translator)

Re: VMS to Unix (was: Is there a Fortran to Ada translator)

[W. Wesley Groleau (Wes)]

There is a FORTRAN-66 to Ada translator in the P.A.L. but it's missing
one compilation unit.

If you're going to use GNAT, why not get g77 also?  That way you can
go as slow as you like with translation.

As for as porting from VMS to Unix: There is available a Unix
implementation of all the VMS libraries.  Even includes TPU, EVE, and LSE.
Vendor claims that it's so compatible you can run tools like CMS on Unix.
I've never tried it, but it sounds like it's worth checking out if you
have to do a fast port.

I tried to find a Web reference for it (since I've thrown away all the ads)
but the search string "VMS near Unix near port*" found 800 URLs....

Your sysadmins probably have it in their junk mail.

---------------------------------------------------------------------------
W. Wesley Groleau (Wes)                                Office: 219-429-4923
Hughes Defense Communications (MS 10-41)                 Home: 219-471-7206
Fort Wayne,  IN   46808                  (Unix): wwgrol@pseserv3.fw.hac.com
---------------------------------------------------------------------------

Re: VMS to Unix (was: Is there a Fortran to Ada translator)

[Oliver Kellogg]

Talking of Fortran, how come the types Fortran_Integer, Real, Complex
etc. in package Interfaces.Fortran are derived types not subtypes?

It seems to me this unnecessarily complicates integration of Fortran and
Ada code.

Oliver Kellogg
Munich, Bavaria

Re: VMS to Unix (was: Is there a Fortran to Ada translator)

[Robert Dewar]

Oliver asks

<<Talking of Fortran, how come the types Fortran_Integer, Real, Complex
etc. in package Interfaces.Fortran are derived types not subtypes?

It seems to me this unnecessarily complicates integration of Fortran and
Ada code.>>


This would introduce nasty implementation dependencies, since of course
in different implementations the base types would differ, so on one
implementation you might be able to assign Fortran_Integer to Integer
without a conversion and on another you would not be able to.

The extra complication introduced by the derived types is precisely
what is needed to ensure proper portability, which is the whole idea
of this interface package.

Re: VMS to Unix (was: Is there a Fortran to Ada translator)

[Mats Weber]

Oliver Kellogg wrote:

> Talking of Fortran, how come the types Fortran_Integer, Real, Complex
> etc. in package Interfaces.Fortran are derived types not subtypes?

Subtypes of what types ? The fact that they are derived from
Standard.Integer, Standard.Float, etc. in GNAT is just because they
happen to have the same ranges.

It could very well be that on an implementation, a Fortran integer is 32
bits and an Ada standard.integer is 64 bits.

In the standard, they are given as

   type Fortran_Integer is range <implementation defined>;

and GNAT chose to derive them from the standard types instead of writing

   type Fortran_Integer is range Integer'First .. Integer'Last;

Re: VMS to Unix (was: Is there a Fortran to Ada translator)

[Robert Dewar]

Mats said

<<In the standard, they are given as

   type Fortran_Integer is range <implementation defined>;

and GNAT chose to derive them from the standard types instead of writing

   type Fortran_Integer is range Integer'First .. Integer'Last;>>



Yes, and this decision was quite intentional. In GNAT working with g77,
we expect type Integer in Ada to be the same as the standard integer
type in Fortran, which is also the same type as int in C.

Now we might come up against a target in the future where this is not
the case, or where the vendor Fortran makes a different choice, and if
so we will worry about how to specialize it then, but the default
assumption is that the types are all the same, hence the use of
derivation.

Now of course it is true that *in GNAT* the declaration that Mats writes
above with an explicit range is always identical in effect to deriving
from Integer, but that is not generally required in Ada semantics (a
compiler is allowed to choose any type that is large enough), so it seems
clearer to state the intent by using a derived type.

Note: we have run into one case so far where we had to break the nice
correspondence of types, namely in the AXP VMS case, where the type
Long_Integer in Ada is 64 bits, where as type long in C is 32 bits.
Since we want to be super-compatible with DEC Ada, we go along with
this decision to make Long_Integer 64 bits, even though it creates
a conflict with the type long in C.

Re: VMS to Unix (was: Is there a Fortran to Ada translator)

[Oliver Kellogg]

Thanks for your comments Robert, Mats. I can see your point.
Frustrated by the permanent necessity of type casting I have
given up using Interfaces.Fortran altogether -- at the price of
forsaking absolute portability to other systems (it so happens that in
my case, Fortran_Integer is the same size as Integer.)

--Oliver