CVF->Intel Fortran->Combined

[jlea]

Steve - its good to see fortran back in the news again and it looks like the new Intel with its .NET support will be our savior. I was just about to sit down with our current VC++/CVF v6.6 projects, create a static lib containing all of our fortran and then see if I can do a build with .NET using the new library. We thought Fortran was going away since all the info about .NET and fortran was from Lahey/Fujitsu, so we were going to either create fortran libraries with v6 of VC++ so we can make the jump to .NET, or have me go home for about a year and connvert our Fortran to C++!! I think I'm too old for that.

I downloaded your paper on porting from CVF to Intel Fortran, and I have a few questions.

1. I use DFLIB one place because I use fullpathqq(). Can I just switch to include 'fgraph.fd'?

2. I use NO_ARG_CHECK in a module file since our fortran uses the classic memory trick of allocating a big chunk of integer common and the slicing pieces of it out for all data structures, integer, real and double precision. CVF would allow that to happen unless I put NO_ARG_CHECK in a module (per your help several years ago). What kind of grief will I have and can it be solved using Intel Fortran?

3. I do the following type of activity quite often:

type (S_SectPartRF), dimension(:), pointer :: tRF
type (S_RestForce), dimension (:), pointer :: partRF

allocate(tRF(numRF),stat=st)
allocate(partRF(numParts),stat=st)

tRF(i).partRF => partRF

will this be a problem with Intel Fortran?

We really would like to go to .NET for a variety of reasons, but our desire to keep the C++/CVF integration was keeping us from not making the jump, so having Intel Fortran and soon the combined product being able to live within .NET is very good news. I know there will be "some" porting issues, there always are, but if there is light at the end of the tunnel, I'm in.

Jon Lea
Leap Software, Inc.
jon@leapsoft.com

[Steven_L_Intel1]

Jon,

You could download the free trial and try these things for yourself, but briefly:

1. FULLPATHQQ is in the "Portability Library" in Intel Fortran - USE IFLPORT to define it (and probably build with /4Yportlib as well.)

2. Remember that the combined compiler will support NO_ARG_CHECK. But if you want to use Intel Fortran for now, you'd have to find other solutions, such as defining the argument as an address passed by value (which means you have to pass loc(var)).

3. Offhand, I don't see a problem with that - looks like standard F95 to me.

A comment regarding .NET. Please try to keep separate in your mind the Visual Studio.NET development environment and the generation (and use) of .NET managed (interpreted) bytecode. Also, note well the Microsoft-enforced wall between languages in the VS.NET environment - you'll still have to build libraries. The major advantage is that you can click "Build Solution" and debug in an integrated environment.

Steve

[jlea]

Thanks Steve - I'll download the trial and see how things go.