A Fortran question
-
Southmountain wrote:
also I searched around and try to find a good IDE for GFortran. any recommendations for such IDEs?
Ehr.. Fortran?? We keep burying VB6. Fortran?? Do we need to shoot it again? Is the Fortran code worth anything? If yes, then maybe rewrite it in a modern language? You made me curious and awaiting your answer.
Bastard Programmer from Hell :suss: "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
Fortran is still used a lot. See Why physicists still use Fortran, and the bottom of this page: IBM100 - FORTRAN.
-
Moreover, since it should not be able to allow (memory) aliasing (since it does not have pointers), a Fortran compiler eventually optimized for esoteric architectures with a high degree of parallelism, could easily be able to distribute computations that involving matrices/tensors (even huge ones) by taking full advantage of specialized computational units. It could do this almost transparently by devolving such computations directly to the hardware. AFAIK, in C99 you can eliminate or limit (mem) aliasing with the
restricttype qualifier.giulicard wrote:
Moreover, since it should not be able to allow (memory) aliasing (since it does not have pointers),
Being around 40 years since I coded Fortran, I have forgotten a lot :-), such as the parameter transfer mechanism. The standard mechanism was call by reference, wasn't it? If a subroutine assigned a value to a formal parameter, the value of the actual parameter would be changed. A reference parameter is equivalent to a pointer. So if you pass the same actual parameter for two formal parameters, you have an aliasing issue. E.g. if the compiler reorders the assignments to the two formal parameters, it might affect the final value of the actual parameter. If some COMMON block variable is used as parameter, and the subroutine refers to the same COMMON variable, you have a similar aliasing issue. In my study years, Pascal was quite new. It didn't become the language for the Introduction to Programming course until the year after I started my studies (and then only for half of the students), so pointers were definitely 'something new'. Yet, in the Compilers course, aliasing issues certainly had a prominent place. Aliasing was treated as exceptional situations; it wasn't something you would worry too much about in Fortran. Even with Pascal and its strongly typed pointers, aliasing wasn't that essential - if the compiler didn't do much optimizing (which was often the case for Pascal compilers), the compiler could play back a 'You asked for it, you got it!' if a programmer referenced the same location along two different paths. Hell didn't break loose until C came with void*, pointer arithmetic, more or less arbitrary casting, and pointers to non-heap locations. Today, we have the processing power and memory capacity to do a more or less complete flow analysis of the compilation unit; in the K&R days, you couldn't expect that. I suspect that compilers were quite fast to conclude, when they encountered a void* or an arbitrary cast, "Oh well, we'll just have to drop all optimization of this one!"
-
Eddy Vluggen wrote:
We keep burying VB6. Fortran?? Do we need to shoot it again?
Don't worry - it was shot, the Fortran giving you nightmares. C.A.R. Hoare was right in his remark to the proposed extensions for Fortran 77: "I don't know what programming languages will look like in year 2000, but they will be named Fortran!" I suspect that if you were presented with sample of modern Fortran code, you would never guess that the language is named Fortran. The evolution from Fortran IV to modern Fortran is more drastic than the evolution of the original thick coax 3 Mbps linear bus Ethernet to the Ethernet of today, using Cat6/RJ45, 1 Gbps, star topology. A couple of years ago, a friend of mine working at the Supercomputing center of the Norwegian Universities. He told me that Fortran (in the modern form) still is a very significant language in supercomputer environments. Lots of scientists / developers find Fortran much more suitable than C/C++ for array manipulation, and lots of engineering problems are essentially array manipulation.
trønderen wrote:
Don't worry - it was shot, the Fortran giving you nightmares.
It was a one night stand.
trønderen wrote:
C.A.R. Hoare was right in his remark to the proposed extensions for Fortran 77: "I don't know what programming languages will look like in year 2000, but they will be named Fortran!"
I'm awaiting Fortran.NET. Most people do not own a supercomputer. The thing that Fortran has going for it, is that it isn't VB6 :)
Bastard Programmer from Hell :suss: "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
Fortran is still used a lot. See Why physicists still use Fortran, and the bottom of this page: IBM100 - FORTRAN.
#define "a lot"? Yours and mine may differ a bit. VB6 is still used "a lot", probably more than Fortran. Most business applications aren't in either language. There's "a lot" of software developed by businesses, "a bit" more than scientists. Being used a lot isn't an argument, but an observation. It might be because lots of scientist learned "just" fortran and cobol in their younger years. That's why Java is a success; many universities refuse any commercial software and hence they prefer what small business doesn't.
Bastard Programmer from Hell :suss: "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
I got some Fortran code with the extension .f. how difficult to run through them in GFortran now? I have touched Fortran since I left school. also I searched around and try to find a good IDE for GFortran. any recommendations for such IDEs?
diligent hands rule....
Check out the GNU Fortran compiler: en.wikipedia.org/wiki/GNU_Fortran gcc.gnu.org/fortran/
-
trønderen wrote:
Don't worry - it was shot, the Fortran giving you nightmares.
It was a one night stand.
trønderen wrote:
C.A.R. Hoare was right in his remark to the proposed extensions for Fortran 77: "I don't know what programming languages will look like in year 2000, but they will be named Fortran!"
I'm awaiting Fortran.NET. Most people do not own a supercomputer. The thing that Fortran has going for it, is that it isn't VB6 :)
Bastard Programmer from Hell :suss: "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
I got some Fortran code with the extension .f. how difficult to run through them in GFortran now? I have touched Fortran since I left school. also I searched around and try to find a good IDE for GFortran. any recommendations for such IDEs?
diligent hands rule....
If you alrady know visual studio, then just get the intel fortan compiler - its FREE to download and use and works well with VS and GITHUB for source control. There are a lot of things fortran can do now as a "modern" version of it, while still being able to leverage existing code.
-
giulicard wrote:
Moreover, since it should not be able to allow (memory) aliasing (since it does not have pointers),
Being around 40 years since I coded Fortran, I have forgotten a lot :-), such as the parameter transfer mechanism. The standard mechanism was call by reference, wasn't it? If a subroutine assigned a value to a formal parameter, the value of the actual parameter would be changed. A reference parameter is equivalent to a pointer. So if you pass the same actual parameter for two formal parameters, you have an aliasing issue. E.g. if the compiler reorders the assignments to the two formal parameters, it might affect the final value of the actual parameter. If some COMMON block variable is used as parameter, and the subroutine refers to the same COMMON variable, you have a similar aliasing issue. In my study years, Pascal was quite new. It didn't become the language for the Introduction to Programming course until the year after I started my studies (and then only for half of the students), so pointers were definitely 'something new'. Yet, in the Compilers course, aliasing issues certainly had a prominent place. Aliasing was treated as exceptional situations; it wasn't something you would worry too much about in Fortran. Even with Pascal and its strongly typed pointers, aliasing wasn't that essential - if the compiler didn't do much optimizing (which was often the case for Pascal compilers), the compiler could play back a 'You asked for it, you got it!' if a programmer referenced the same location along two different paths. Hell didn't break loose until C came with void*, pointer arithmetic, more or less arbitrary casting, and pointers to non-heap locations. Today, we have the processing power and memory capacity to do a more or less complete flow analysis of the compilation unit; in the K&R days, you couldn't expect that. I suspect that compilers were quite fast to conclude, when they encountered a void* or an arbitrary cast, "Oh well, we'll just have to drop all optimization of this one!"
Unfortunately, I too am old. :-) I started writing software as a professional back in 1984 (Alpha Microsystem with MC68000, AMOS/L, AlphaBasic, then AlphaC... Assembly, etc, etc), and years ago the information came from magazine articles. I remember reading things about the Fortran compiler of a Cray system or other supercomputer manufacturer, saying that their Fortran compiler pushed entire matrices into the memory of hardware dedicated to matrix computation or something like that. The level of hardware parallelism, according to them, was very high for that kind of computation. But it's been almost 40 years (or maybe more) and I don't remember any of the details anymore. But this information, that Fortran facilitated the use of scientific algorithms on dedicated hardware because of the fact that it freed the optimizers of the time from looking for aliasing, has always stuck in my memory. For that matter, expecting a pointer in main memory to be able to point to an address in a block of RAM within a number-crunching subsystem, I see that as a very difficult thing to achieve. It may be because for 20 years I have also been designing digital hardware, from discrete systems to using the first Quicklogic FPGAs that appeared in the early 1990s, so I can humbly say that a modicum of the idea of how things work inside hardware I may well have. I guess if we are referring to a mainstream compiler things are straightforward as you state. But on architectures of yesteryear devoted to hard numerical computation, I think the principles of a current compiler are not easily applicable. Others architectures, others optimizers. That said, I have only touched on Fortran very occasionally. The last time, well over a decade ago, I helped a colleague import a library for crunching huge matrices. It was written in Fortran. These algorithms worked a particular type of not regular matrices. The purpose was of calculating price indices for inflation forecasting for a government agency, but I ignore completely the mathematical principles at the base. Sorry for the bad elglish. Regards
-
If you alrady know visual studio, then just get the intel fortan compiler - its FREE to download and use and works well with VS and GITHUB for source control. There are a lot of things fortran can do now as a "modern" version of it, while still being able to leverage existing code.
thanks for the great info! I definitely try this configuration!
diligent hands rule....
-
Eddy Vluggen wrote:
Is the Fortran code worth anything? If yes, then maybe rewrite it in a modern language?
"If if works, don't fix it!" Rewriting software to a potentially poorly suited other language, just because that other language is fashionable in many software development communities, may be a bad idea. Not always, but you need some stronger arguments than "We don't think Fortran IV reflects modern ideas about programming languages."
Hear hear!