Slashdot Mirror

A bit of satire from the 70's https://www.fortran.com/come_f...

I love to use the ComeFrom statement. It just makes the logic of the program so much easier to follow when others need to apply that very rare patch to my code.

Hollerith constants Equivalences Computed Gotos Arithmetic Ifs Common blocks

And my personal all time favourite - the ComeFrom Statement.

*delicate shudder*

For FORTRAN: http://www.fortran.com/

For Ada: http://www.adahome.com/

HTH

I think as well as things like GIVENWHEN or GOTO it might also include the COMEFROM statement.

First of all, if variables starting with i to n are integers, could variables starting with a to h be declared as integers too? If not, then the joke doesn't work in Fortran.

There's also an IMPLICIT directive so you can change the compiler's idea of what type to assume for undeclared variables. IMPLICIT NONE was introduced at some stage (or might be a vendor-specific) and was actually a requirement in the coding standards at one place I worked.

Note: the implicit rules also apply to function names.

There's a wealth of info at http://www.fortran.com/ in case you have to learn the language quickly. It isn't difficult, but might come as a shock to anyone who only has experience of modern languages.

You're both wrong, though trivially so. IMPLICIT NONE isn't ANSI FORTRAN 77; it's MIL-STD 1753, which is rarely not implemented by ANSI FORTRAN 77 compilers. (And it's Fortran 90 as well.) But it does basically what you say (that is, override the default used by Fortran 77 and most of its predecessors and successors).

The GP wrote "IMPLICIT DOUBLE F". Actually, it's written "IMPLICIT DOUBLE PRECISION (F)".

Also, the only thing I saw with the GGP's program, as an ANSI FORTRAN 77 (or earlier?) program, was that the program name was more than six characters long, and contained an underscore. I think it's fine as a Fortran 90 program. It doesn't need to use IMPLICIT NONE in any case, since it uses no variables or functions.

And when you're done with that you could move on to E and F....

Reverse execution? Are we finally going to see an implementation of the COME FROM statement?

(See also the entry in the jargon file.)

Fixed-dimension arrays don't use pointers to any greater or lesser degree than Fortran arrays do. And non-fixed-dimension arrays are dealt with via pointers, so it's obvious that you're using a pointer ;)

It seems like you're missing the point. In Fortran you are simply not allowed to call a subroutine using arguments that overlap in memory. [Fortran 77 standard, sec. 15.9.3.6] So the compiler can parallelize the array assignment example that was given while still conforming to the language standard.

In the new 1999 C standard, you can give the compiler a similar guarantee using the semantic declaration restrict. And independently of that, some C or C-like compilers can take #pragma directives or nonstandard extensions for similar purpose.

This improvement to C has put somewhat of a damper on the parallel-(C vs. Fortran) debate, but Fortran still has a small advantage in this area. In particular, it is much easier for a human to find aliasing in Fortran than in C, since you have to go out of your way (using EQUIVALENCE, POINTER, etc.) to accomplish it.

And of course, neither language has compilers that can actually tell whether a given program is violating the semantic rules I have mentioned... this would be like expecting a compiler to find memory leaks. Though presumably tools like valgrind can be used to help find possible problems with aliasing.

They have been predicting the demise of programmers since the invention of COBOL in the 60s. It was supposed to turn ordinary business users into programmers thanks to its easy, English-like syntax. We're still waiting. Now this writer is talking about running out of programmers capable of maintaining code that was presumably easy to write and maintain?

I think you mistake COBOL for ALGOL. The latter was indeed advertised for it's "ease of use" and it started a long line of (supposedly) user friendly languages, through it direct descendant - Basic - to contemporary Visual Basic and AppleScript. Cobol was rather advertised as being "business friendly" because it allowed ease separation of data and code and that - allegedly - suited it better for business/office data processing than its main competitor, Fortran. Noone could seriously predict "demise of programmers" in early 1960's. There were no personal computers in present meaning - even the so called minis of the PDP family, still required a separate room, had a price of a small airplane and were operated by dedicated staff wearing lab suits.

I wouldn't put much blame on GNU. Fortran 77 was a fairly unpleasant language, even before GNU existed. Compiler extensions sometimes helped but weren't too great for portability.

Not that I don't want to see a GNU Fortran 95, but if you can tolerate free as in beer software, Intel makes their fortran compiler available for free for noncommercial use on Linux: IFC

There is also the F programming language which is a (mostly) tastefully selected subset of Fortran 95: F. Mostly it just throws out redundant features and stuff inherited from Fortran 77. It's a little picky in a teaching-language sort of way and takes some getting used to, but I have ported code to F without pulling my hair out. And the code did end up a bit clearer for the changes.

Let's not forget this bit of fun. We can banish goto forever now that someone finally invented
comefrom.

If you are after a Fortran like compiler, there is the F compiler. F is a language that is a subset of Fortran 95. The F compiler is free (check the licence, its been a while since I used it) and can be found here.

From what I remember the F language supports a large and usefull subset of the Fortran 95 language and the compiler is based on the NAG compiler, so should produce pretty reasonable code.

Naturally we shouldn't be overly concerned that Athena doesn't meet a "proven" (here, POSIX) standard--we aren't all using FORTRAN or writing real-time [deterministic-time] algorithms, are we?--, but shouldn't we take a moment to consider the fact that Athena's FAQ says:
["Does the Pandora Engine support POSIX compliancy?"]
"No. It's not practical, or even possible to implement most of the POSIX standard" (my bold)
because:
"POSIX was designed for procedural systems, so given that the Pandora Engine is object based..."
Now, it is of course a Good Thing (for easy, modular programming) to have a heavily OOP'd, high-level 'environment', (we can't even say OS anymore[1]) that can easily optimize later whatever tasks it does allow the application to run. However, the fact should worry us that the developers say it is not "possible" to run functions on a low enough level to ensure any kind of guaranteed (or "realtime" :) operational behavior on ANY level of what you're doing...short of writing bits out to a file (but you're getting nowhere near the FS--or any hardware for that matter). Forget HAL: this is HAL:THISMACHINE:HARDWARE:PERIPHERALS:OUTPUT:VISIBL E:MONITORS:ENVIRONMENT:WINDOWS:MYWINDOW:PLEASE:PRE TTY:PLEASE:LET:ME:NEAR:A:SET:METHOD(&MyAthenaApp.m ywindow.mypallette.color, GREEN); Not that this isn't useful, but what if their idea of green isn't your idea of green? Just dig around the standard, right, it's bound to be there somewhere?
"Pandora does not use a separate interface for game development (such as a DirectX style API)"..."Currently we are missing 3D support (OpenGL for example)"...Hmmmm...correct me if I'm wrong, but does this mean that their "object based" methods are the only things programmers will have available, without even the Standardizd (eg OpenGL) niceties we can use to get around protected architectures once they're implemented?
Oh well: "there are plenty of existing engines that can be ported when the need for a 3D engine arises."
But I wonder...does "can be ported" mean "We can't exactly use them, because of how commercial we are, and we're not allowed to port GNU stuff, but, we assure you, we'll have really, really similar-sounding naming schemes..." ;-)
Anyone see a different take on this?

[1] Athena on BeOs on WIN2K on Linux??? Oh the thngs we do. :)

I have to admit that I am biased (in large part due to my employer). I would not consider a dual PII generally a good multiprocessor for numerically intensive codes. This has nothing to do with Intel or Linux, or g77/pgf77/absoft, etc.

What I have found on my codes is that small (actually tiny) problems run well on pentia. But reasonable research sized problems cause it to huff and puff. Machines like the alpha or the R10k (and R12k) kick serious butt on the larger problem sizes. What is just insanely cool is to watch your code (efficiently) use all 32 processors, and get something like a 28-30x speedup.

But, as I said, I am biased.

Back to fortran. Jeff Templon has an excellent page on Linux and Fortran. Better is the big fortran link page. This is really a nice resource and is a nice intro to the general Fortran Market setup by Walt Brainerd. I strongly advise visiting this site if you need to think Fortran.

Ok, now some thoughts. Craig Burley and crew have done a positively bang up job on g77. It is IMO a useful productive research tool... with a caveat or two.

First, it really is just a front end to the gcc back end, so there are many... gcc-isms... floating about.

Second, while optimization is OK, it is generally tied to the gcc optimization, which has traditionally not been very good. The egcs project has had a much better track record on getting real optimization into the compiler. Folks, if your runs can take years, 5% DOES matter. Optimization on pentia is not just -O, you need things like

-O3 -malign-double -malign-functions=2 -funroll-loops -ffast-math

among others for decent performance.

Third, and most important for me, it (nor egcs) knows nothing whatsoever about multiprocessing.

In short, g77 and egcs in general are awesome tools. But unless you work on small problems, they are not suitable. You will need some better tools, and that involves passing over some money in this case.

I like the Portland Group tools, though the KAI tools are effectively identical to what you use on big supers like Origins. Unfortunately, I do not think KAI supports Linux any longer. Maybe we can all write them a nice letter on how they could drop support for some underused platform for computation (some come to mind here :-) ) in favor of Linux. Market size and all that.

As the author of the referant article wrote, most fortran users want all the speed they can get, so you need to look at what your code spends the most time doing, and figure out if it is doing it the right and most efficient way, or if your system is correctly designed for speed, or if you are hitting one area of your system really hard, and thus causing a bottleneck. In short, if you need to design for speed, start out with a workstation design, and not a PC design. You likely will need massive memory and IO bandwidth to complement an insanely fast CPU. Putting an Alpha into a PC architecture should be considered a capital crime. It makes much more sense to put it into something like a DS20, a T3E or some other design (I can fantasize about an Alpha in an Octane or an Origin, that would be a complete screamer... a memory and IO bus capable of feeding the processor at its full speed... shudder).

The language and its implementation are important, but so is the fundamental system design. You need to avoid bottlenecks everywhere.

Joe