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.
Related
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'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.
Seems all compilers can deal with both c and c++,like gcc ,msvc...
Is it because these 2 languages are exactly very much alike?
Actually, GCC (GNU Compiler Collection) has two different front-ends, gcc and g++. To specify C++, you can also use a .cpp (or a few others) extension, or -x c++, when executing gcc. However, this requires extra options (like linking in the C++ standard library).
cl, Microsoft's C++ compiler, does not support modern C. However, it will compile C source files as a variant of C89, and you can specify this explicitly with /TC.
For both, you are correct that there's a lot of shared code, regardless of which front-end is used (GCC also has many more). However, the languages do have significant differences, which are discussed elsewhere (this question among others).
There is no dedicated compiler for C/C++ because there is no such language....
If you are going to write a C++ compiler then you will have to be able to compile C too, so you may as well also provide one.
There may still be some C compilers around that do not have a companion C++ compiler with them though.
No. That's not true. Look at Pelles which is a C only compiler.
The semantics of the core language constructs for C and C++ remain more or less identical, and C++ was designed to add structural elements to C rather than change or remove existing language features. Therefore if you go to the trouble to build a C++ compiler, having it also compile C is relatively trivial (at least for ISO C90). C99 diverges in some significant ways from C++, and some C++ compilers either do not support C99, or include C99 features as extensions in their C++ compiler.
C++ is also highly inteoperable with C, C++ for example wholly includes ISO C90's standard library, and can link any C library. C++ libraries can be given a C linkage compatible interface for use by C code (although that is often less straightforward than C++ calling C code).
Early C++ tools were not true compilers, but rather C++ translators, which generated C code for compilation by a native C compiler. Comeau C++ still takes this approach in order to support C++ on any target with a C compiler, which is useful in embedded environments where some targets are not well served by C++ tools.
TCC is an example of a C compiler which is not a C++ compiler. Actually compiling C++ is a huge pain; the only reason so many C compilers also support C++ is that there's a pretty big demand for C++.
C++ is a superset of C. I don't know if this is still true, but it at least used to be common for c++ compilers to convert code to C as a first step in compiling.
Edit:
I've always heard that it is a superset. Since GMan says no, I looked at Wikipedia which says, "C++ is often considered to be a superset of C, but this is not strictly true.[21] Most C code can easily be made to compile correctly in C++, but there are a few differences that cause some valid C code to be invalid in C++, or to behave differently in C++." (See http://en.wikipedia.org/wiki/C%2B%2B for details.) So I stand a bit corrected.
Edit 2:
I've read a bit further in the Wikipedia article. Sounds like this is more accurate: C++ started as C; C++ evolved by adding new features to C. At some point, C++ changed enough to no longer be a pure superset of C. Since then, C has also evolved, and now has some features that C++ doesn't. So they're closely related, but no longer wholly compatible with each other.
No, LCC compiler is for C only.
GCC has gcc and the g++ components which compile C and C++ code.
clang-llvm has a C front-end. There is an experimental, separate C++ front-end.
IBM's Visual Age is split into xlc and xlC compilers.
Portable C Compiler is C only.
Last time I used it, Labwindows/CVI suite by National Instruments was a C only compiler.
It isn't true, there are several, and there were plenty in the 1980s before C++ compiler products started to appear :-) However given a C++ compiler the marginal cost of producing a C compiler out of the same codebase is relatively small, and even going the other way isn't a major increment, at least compared tom starting from scratch with either.
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.
Does C++ code gets converted to C before compilation ?
A few C++ compilers (the original cfront, Comeau C++) use C as an intermediate language during compilation. Most C++ compilers use other intermediate langauges (e.g. llvm).
Edit: Since there seems to be some misunderstanding about the history: "C with classes" started out using a preprocessor called "Cpre". At that time, it was seen strictly as a dialect of C, not a separate language in itself. In December 1983, people were starting to view it as a separate language, and the name C++ was invented. As it happens, development of cfront started in April 1983, so a reasonably usable version became available (to a select few) just about the same time as the name "C++" came into use. This appears to be mostly coincidence though.
As far as producing C as its output, that was really quite common on Unix. Just for example, the Berkeley Pascal compiler and at least a couple of Fortran compilers also produced C as their output.
There is, however, a huge difference between Cpre and Cfront. Although both produced C as their output, Cpre did virtually no syntax checking of its own -- it looked for a few specific things, and did a relatively mechanical translation on them. It wasn't until the C compiler looked at the result that real syntactical analysis was done. If your code contained a syntax error, it was almost certain that it wouldn't be caught until the C compiler parsed the output from Cpre.
Cfront, however, did full syntactical analysis of the source code itself, so (short of a bug in its code generator) you'd never see a syntax error from the C compiler. The C compiler was simply used as a code generator so nobody needed to rewrite CFront to accommodate different processors, object file formats, etc.
If you want to get into more detail, chapter 2 of The Design and Evolution of C++ is devoted almost entirely to the "C with Classes" time frame (and there are various other details about it spread throughout the book).
No, but like most myths there's a shred of truth to this. The original compiler for C with classes (which later became C++) was nicknamed CFront and did translate to C.
Not in most modern compilers.
The original C++ compiler was actually a preprocessor however. It generated C code, which was then compiled by a C compiler.
In the early days of C++ compilers, some did it that way. I haven't seen a C++ compiler implemented that way since the late 1980s however.
As others have answered. NO.
However if you want to use an OOP language like C#, and have your code compiled into C I recommend you take a look at Vala.
the title seems to ask is C++ a superset of C, i.e. can you just dump any c code in a c++ compiler and it will work? In which case, yes it is, sort of...
one major difference is that C automatically casts pointers for you, c++ does not, you need to cast the manually...
any one remember anything else?
thats all I remember from the horrible process of converting a massive C project to compile under c++ for some reason...