Is there an converter from fortran 90 downto fortran 77 ?
I have a fortran77 only compiler and want to run NAS Parallel Benchmark (NPB for short) on it.
But NPB uses some features of F90, like do enddo, smth else. All features are rather simple.
Is there A way to translate NPB to F77 strict language?
Tags: fortran parallel convert programming-languages
I need tool to lower minimally
DO ... ENDDO
and
DO ... WHILE
to DO with number labels and to DO + IF
There are converters from FORTRAN 77 to Fortran 90, but I have never heard of one for the other direction. I expect that there is very little demand for such. DO ... END DO and DO ... WHILE were common extensions supported by FORTRAN 77 compilers, so these features in the source code may not be signs of using limited Fortran 90 but of using typical but non-strict FORTRAN 77. Why stick with a FORTRAN 77 compiler? Why not download gfortran or another modern compiler?
The DMS Software Reengineering Toolkit is used to carry out program transformations on large applications in many languages.
It has a full Fortran 95 front end, and can apply source-to-source rewrites to code.
Since F77 is pretty much a subset of F95, you can implement your conversion by applying
rewrites that map F95 constructs into the corresponding F77 idioms still in F95.
You examples of transforming structured DO blocks into F77 code with gotos and line numbers would be pretty straightforward. There are likely to be lots of other changes (F95 has strings, structures, modules, ...) but which ones you'd have to transform depend on precisely what's in the source code base of interest.
Related
Yep I know.., this is not imagined ... it's a real Fortran question.
By previous versions I mean Fortran 2003, 95, 90, and even 77.
by backwards compatible I mean can easily run code written for previous versions in 2008 (with nothing more than some minor changes to syntax)?
Nothing was deleted in Fortran 90 but some awful features have been deleted in Fortran 95 and later. More have been marked as "obsolescent". See, e.g., http://www.cisl.ucar.edu/zine/96/fall/articles/3.f90.obsolete.html. As a practical matter compiler vendors still include these features because there is so much legacy code out there. There would be customer rebellion if compilers couldn't compile legacy FORTRAN 77 programs.
Sure. This is all what Fortran is about, which is backward compatibility. Often, one expects that the Fortran standard is supported for the next 50 years (not kidding). You can still compile a Fortran 66 code with the intel compiler which supports most features of 2008 standard.
Today I was reading code from some very popular numerical libraries written in FORTRAN 77 such as QUADPACK (last updated in 1987), and I was wondering if there is any reason not to rewrite those libraries in Fortran 90 apart from the big amount of work it would pose, given the great improvements Fortran 90 brought to the language, including free-form source, better control structures so GO TO could be forgotten, vectorization, interfaces and so on.
Is it because FORTRAN 77 compilers produce more optimized code, maybe it is better for parallel execution? Notice that I'm not even talking about Fortran 2003 for example, which is only 8 years old: I'm talking about Fortran 90, so I assume it has enough widespread and the compilers are ready. I don't have contact with the industry, anyway.
Edit: janneb is right: LAPACK is actually written in Fortran 90.
Well, like "pst" mentioned, the "big amount of work it would pose" is a pretty major reason.
Some further minor points:
LAPACK IS Fortran 90, these days, in the sense that the latest version no longer compiles with a F77 compiler. That being said, it's far from a rewrite, only a few things that were changed.
Most of the F90 features you mention make it easier and faster to write robust programs, it doesn't necessary make the resulting programs any faster.
It wasn't that long ago that free F90 compilers were not available (plenty of people used g77!), so for a widely used library like LAPACK not using F90 features was likely a conscious decision.
A F77 compiler does not, generally, produce faster code than a F90 compiler. If not for any other reason, then because it's likely obsolete and cannot optimize for the latest CPU's. A modern Fortran compiler might create faster code from F77 than from an equivalent F90 program which makes extensive use of things like pointers etc., but that is highly dependent on the program in question (e.g. using pointers and fancier data structures may allow usage of better algorithms, allowing the F90 program to produce results faster even though it might execute at a lower average utilization of the CPU arithmetic units).
Vectorization, if by this you mean the F90+ array syntax, is mostly a programmer convenience issue rather than allowing faster code. A competent compiler will vectorize the equivalent DO loop just as well.
There is no reason to put in a ton of work to (maybe) improve something that works well. It should be noted that even though Fortran 90 introduced many new features, it did not change the language. Remember that Fortran 90 Standard is backwards compatible with FORTRAN 77. A modern compiler will be able to optimize a FORTRAN 77 code just as well. There are features introduced in Fortan 90 (e.g. pointers) that would hinder the efficiency and that should be avoided if one cares about execution time, e.g. in HPC.
So it would not really make a difference. For a modern compiler, well written FORTAN 77 is just as optimizable - it is like a cake without icing. Here, in case of Fortran 90 and later, icing looks better than it tastes - it is a convenience for the programmer, but does not necessarily improve the program efficiency.
There is one major reason why Fortran 77 programs might be faster :
Allocated arrays (Fortran 90) are much slower than declared-at-compile-time arrays.
Both are not put at the same place in memory. That's the stack vs heap memory management in Fortran.
See here for instance
This being said, Fortran 90+ have fast 'all in block' array operations. I'm a big fan of gcc-fortran (gfortran) and without any compilation option, for an array a of size N
a = a + 1
is 4 times faster than
do i = 1 , N
a(i) = a(i) + 1
end do
This bench is for me, on my machine, on gfortran without optimization option, and without any claming that this is professional benchmarking.
The allocation "problem" (which is not a problem but a feature) is not architecture, compiler or anything related but to the Fortran Standard.
Whether F77 program will be slower or faster then the equivalent F90 program, rewritten with newer syntax is discussable, but let's disregard that for now.
What should however be taken into account, is that nobody really cares about speed only. People only care about speed of execution in the cases where it is relevant, and where it is bussiness profitable (I'm sure there is a better term for this, but nothing comes to mind right now ... cost effective maybe).
Since those two (rather popular libraries) are still in F77, it is obvious that it is the general opinion that the costs of rewriting them outweights the benefits gained, benefits in term of speed of execution, and benefits in terms of cost effectiveness of that whole process.
I was wondering which high-level langunage allows the easiest manner in which to call Fortran subroutines? I currently use MATLAB and calling MEX files seems to be relatively complicated compared to other languages.
I'm particularly interested in how the following compares in terms of getting "up and running" quickly:
*Python via f2py
*R via ?
*MATLAB via MEX files
Another way of asking this would be "If you were to start over and learn a new language, which one would you choose if your objective was calling Fortran subroutines?"
I'm trying to getbthe "best of both worlds" i.e. having good data handling and graphics combined with the ability to call fast Fortran subroutines.
Thank you all in advance for any help you can provide. Alas, if someone knows of a good MEX tutorial for Fortran, that would be appreciated as well.
I was wondering which high-level langunage allows the easiest manner in which to call Fortran subroutines?
The obvious answer is Fortran itself. So-called Modern Fortran (2003 & 2008) has a lot of high-level features. And obviously it's easy to call legacy FORTRAN code (my guess is that you have old FORTRAN code base) from the modern one.
Python via f2py is very nice. I had a little bit of trouble getting it going on Windows with IVF, but it didn't take long to figure out, and the mailing list gives prompt responses. On Linux, it worked without any issues.
I haven't used R, but as I understand it, it's only useful if you do a lot of statistics with large amounts of data. As for MATLAB, it's a horrible language, if you're just calling FORTRAN, you're better off with Python.
What I usually do in your case is create Fortran programs that I can pass command line arguments to as input. This is readily available by Fortran 2003 standard using intrinsic get_command_argument subroutine. You can then parse Fortran program output from whatever language you are using as a wrapper (assuming language has access to system shell). In the past, I did this with shell scripts, MATLAB (avoid), Python.
I've got some code I need to run, written in FORTRAN IV. What are my options for running this code? Is there an application out there that can compile and run FORTRAN IV code on a PC? Or if possible I am looking for a utility to convert Fortran IV code to FORTRAN 77 or later. I have little experience in Fortran and in programing in general.
Thanks for you help
Intel's Fortran compiler supports Fortran IV. If you don't want to go that way, there are some conversion utilities mentioned in this question --- but none of them sound very promising.
Very few features have been deleted from Fortran. A few more features have been marked as obsolescent in the more recent language standards. But the compilers tend to support most or all of these features because some customers don't want to recode working legacy programs just because they use "bad" features. Sometimes one has to use compiler options to use some of these features. So I'd just pick a compiler and try it on the existing code. There are many to choose from. Maybe get a trial version to see whether it works before paying your money or use a free one.
Another possible problem is that your code base might have non-standard features. In pre Fortran-90 days there was less concern with language standards and some vendors added extra features for user convenience and to differentiate their product. If present, such features might cause greater problems and require recoding.
Probably the most important feature of Fortran IV is that do loops check the variable at the end. Thus do loops always execute at least once. This was a big issue when it was changed to the current method.
n = 5
do 99 i = n, 4
write(*,*) i
99 continue
Will print out "5" in Fortran IV, and nothing in Fortran 77. Codes that use this feature can be hard to port.
I'll just add that if the code does use non-standard features that your compiler doesn't handle, the maintainers at fortranwiki.org maintain a nice list of explanations of, and workarounds for, many such contstructs on their Modernizing Old Fortran page.
The obvious answer is to run it as is on MVS 3.8J under the Hercules emulator. MVS 3.8J and IBM FORTRAN G and FORTRAN H are public domain.
You will be able to compile and run the code as if you had a real mainframe! The IBM FORTRAN compilers support (defined, actually) the full FORTRAN IV language along with IBM extensions.
I'm attempting to work in Fotran 77, and I've found the need for a tree based data structure. Aside from implementing a tree with an array, is there any way to build a tree with pointer nodes to other nodes, as per a standard implementation in most languages?
The documentation for this beast is scarce, and there doesn't appear to be any standard structure type that would make this possible.
Thoughts?
I suggest you move to Fortran 90 or later. FORTRAN77 and earlier didn't have pointers in the language specification, so compiler writers (and users) came up with a whole raft of clever* ways of adding the necessary functionality to do just the sort of thing you want to do. Fortran 90 has proper pointers for dynamic data structures.
clever* means, of course requiring advanced programming skills and understanding of memory, pointers, referencing and de-referencing (all of which are alien to most Fortran programmers) with the inevitable consequence that clever* programs are not portable between compilers, nor between hardware platforms, nor between programmers.
I don't understand why you would be restricted to working in FORTRAN77 -- standard FORTRAN77 remains syntactically correct and compilable with Fortran 90 compilers. Sure, you have to integrate your new tree-processing code with the existing codebase in the old language, but that doesn't mean that you have to write new units in the old language.
And, in passing, FORTRAN77 was way more modern than FORTRANII.
This would be much easier in Fortran 95/2003, which has user-defined derived types and pointer types. Using these features one can setup data structures such as linked lists and trees. (The pointer types are called pointers, but they are more like alias, in that pointer arithmetic isn't possible). Fortran >=95 has many improvements over Fortran 77. My recommendation is not to use Fortran 77 unless one is making minor modifications to legacy code that is in Fortran 77. A good book is "Fortran 95/2003 explained" by Metcalf, Reid and Cohen.
If you're really stuck with Fortran-77, you can use Cray Pointers:
http://gcc.gnu.org/onlinedocs/gfortran/Cray-pointers.html
Cray Pointers are non-standard and have some drawbacks, but they'll give you something similar to a C pointer. They're supported by gfortran and most commercial compilers.
With that said, you would probably be better off using newer Fortran features, like Fortran-90 pointers or the C-interoperability features in Fortran 2003.
Without Cray pointers or other hackery, the only way to implement a "data type" is with parallel arrays, each of which represents a field. An index, then, can refer to an instantiation of the data type.