cdshaw@alberta.UUCP (Chris Shaw) (03/18/88)
In article <24861@yale-celray.yale.UUCP> leichter@yale-celray.UUCP (Jerry Leichter) writes: > >Maybe the >REASON the scientific community like FORTRAN is that it ALLOWS them to "play >around". ... >A common thing >to do is to allocate a large one-dimensional array and carve variable-sized >2-D arrays out of it. The way this is done is ugly, because FORTRAN has no >inherent ability to deal with dynamic memory allocation so it all has to be >faked. ^^^^^^^^^^^^^^^^^^^ ^^^^^ > If the code had been done in C, for example, the space would have been >allocated with malloc(). Of course, that doesn't really give the a compiler >much more to go on than was available in the FORTRAN case! Not true! >Before proposing to remove something so central to large codes, you'd better >understand WHY it's central, and what you can provide to replace it with. > -- Jerry I think the reason that the scientific community likes FORTRAN is that the scientific community likes FORTRAN. There are huge libraries of code that solves most of the boring details of your problem, so all you have to do is code up the I/O and the mainline (gross amounts of handwaving here) and bob's your uncle. Well fine. But it's a software engineering horror, and everyone knows it. Just because it's standard to carve a chunk out of an array doesn't mean that this is the best way of doing things. Jerry carelessly mentions the possibility of doing numerical codes in C, and basically states that things would be no different. Well, I HAVE done this and the benefits are considerable. I translated a subset of SPARSPAK, a sparse matrix package, to C. Although there is not much difference on the face of it, there is substantially less effort spent on garbage programming. True, you get arrays with unknown initial sizes. But 1) Somebody else is doing the garbage collection and storage management. This is the way it SHOULD be. It's the compiler's job. No-one's going to claim for a moment that a scientist who can barely program coherently is going to spend the amount of time it takes to get his storage management right. The scientist wants answers, and storage management doesn't give answers. 2) There is no compiled-in upper bound on the size of the problem you have to solve. With malloc, you can either solve the problem on the machine or you can't. Given flexible code, there is never going to be a situation where you have to dink with the code every time a new-sized problem comes up. The point being, of course, that creating flexible programs is MUCH easier in C than FORTRAN. In sum, the reason WHY the carve-array paradigm is central to FORTRAN is that one is FORCED into using it. Getting back to the SPARSPAK example, I found that solving stuff with C-SPARSPAK was much easier than the FORTRAN version, since I only had to compile once. This allowed me to concentrate almost entirely on the problem at hand. -- Chris Shaw cdshaw@alberta.UUCP (via watmath, ihnp4 or ubc-vision) University of Alberta CatchPhrase: Bogus as HELL !
haynes@ucscc.UCSC.EDU (99700000) (03/19/88)
We have to keep in mind that FORTRAN was originally designed to make it easier to program one architecture, the IBM 704 with up to 4K of 36-bit memory. I believe the whole idea of a language as a machine-independent way to program evolved later (correct/flame me if I'm wrong). So getting the machine-dependent features out of the language has been like pulling teeth. I remember a scientist telling me a few years ago that he had been forced to learn Fortran IV because Fortran II wasn't available anymore on any machine he had access to. Also Fortran was created before there were any operating systems. I remember some 704 users complaining loudly when their machine was replaced by a 7090 and they didn't have the control over the machine they were used to having. They had to learn to live with a monitor that would throw their program off the machine when something went wrong, rather than halting so they could inspect and change memory contents through the console. haynes@ucscc.ucsc.edu haynes@ucscc.bitnet ..ucbvax!ucscc!haynes
aglew@ccvaxa.UUCP (03/20/88)
..> Chris Shaw on SPARSPAK
(1) Is it possible to give out your C-SPARSPAK?
(2) Do you have any ideas as to what a (vector) processor
can do to make sparse matrix codes run faster?lisper-bjorn@CS.YALE.EDU (Bjorn Lisper) (03/21/88)
In article <2424@saturn.ucsc.edu> haynes@ucscc.UCSC.EDU (Jim Haynes) writes: >We have to keep in mind that FORTRAN was originally designed to >make it easier to program one architecture, the IBM 704 with up >to 4K of 36-bit memory. I believe the whole idea of a language >as a machine-independent way to program evolved later (correct/flame >me if I'm wrong). So getting the machine-dependent features out >of the language has been like pulling teeth. .... I've been told that arithmetic IF in FORTRAN, IF (E) L1,L2,L3 where E is an arithmetic expression and L1 - L3 are lines in the program to jump to dependent on the sign of E, translated, except for the evaluation of E, to one single instruction on that machine. The instruction repertoire of old IBM machines also had an impact on other "high-level" languages, like for instance LISP. CAR and CDR were apparently the names of instructions to access left and right halfword, respectively, on the IBM 7090. The CAR and CDR pointers were stored in halfwords in this manner in this LISP system. Bjorn Lisper
lisper-bjorn@CS.YALE.EDU (Bjorn Lisper) (03/21/88)
In article <28200126@ccvaxa> aglew@ccvaxa.UUCP writes: > >..> Chris Shaw on SPARSPAK .... >(2) Do you have any ideas as to what a (vector) processor > can do to make sparse matrix codes run faster? If the sparse matrix code is such that the vector instructions can be utilized, yes. Multifrontal methods, for instance, allows this to some degree. They are direct methods that work by breaking down the total, sparse system to a tree of dense subsystems where each can be solved with the use of vector instructions. When all sons to a node are solved the solutions of the sons are combined with the equation system of the node itself which in turn is solved, until all equations are solved. Another possibility is if the machine has instructions for gathering and scattering vector elements, then these can be used to increase the possible vectorization. A paper on this is Lewis, Simon: "The Impact of Hardware Gather/Scatter on Sparse Gaussian Elimination", SIAM J. Stat. Comput., vol. 9, no. 2, March 1988. Bjorn Lisper
alan@pdn.UUCP (Alan Lovejoy) (03/22/88)
In article <1135@pembina.UUCP> cdshaw@pembina.UUCP (Chris Shaw) writes: >In article <24861@yale-celray.yale.UUCP> leichter@yale-celray.UUCP (Jerry Leichter) writes: >I think the reason that the scientific community likes FORTRAN is that the >scientific community likes FORTRAN. There are huge libraries of code that solves >most of the boring details of your problem, so all you have to do is code up >the I/O and the mainline (gross amounts of handwaving here) and bob's your >uncle. > >Well fine. But it's a software engineering horror, and everyone knows it. Just >because it's standard to carve a chunk out of an array doesn't mean that this >is the best way of doing things. Jerry carelessly mentions the possibility of >doing numerical codes in C, and basically states that things would be no >different. Well, I HAVE done this and the benefits are considerable. I >translated a subset of SPARSPAK, a sparse matrix package, to C. The other reason is that FORTRAN programmers are interested in raw performance above all else. They are perfectly happy to twiddle the source code to get the maximum performance for each specific problem, recompile, run the program, twiddle the code for the next similar but slightly different problem, recompile.... Generic code written using abstract notation that permits the same object code to work with arrays (or other collections) of arbitrary size and/or with numbers which can freely be chosen from among REAL, INTEGER, COMPLEX, matrix, polynomial, numeric-valued-function or user-defined values is of little interest to people whose main concern is performance. They don't mind having one subroutine for gaussian elimination of 25 by 132 matrices of 32-bit real numbers, one for 834 by 1077 matrices of complex numbers, etc. Does the next problem require a different size matrix? That's ok, they'll just twiddle the code and recompile. Does the next problem call for complex numbers using 64-bit reals? They'll just make a copy of the one for 32-bit reals and use the editor's global replace to change the data types as appropriate. Of course, all code is written for maximum performance on the machine which will be used to run it. When a new machine with a new architecture comes along, the code will be twiddled for maximum performance on the new machine. Performance is an OBSESSION with these people. Perhaps rightly so in some or even most cases. When Ada (Modula-2, C, C++, ML, Oberon, whatever the latest and greatest language is...) compilers can produce significantly faster code than FORTRAN compilers, even when the full complement of abstraction mechanisms are used, then you MIGHT be able to interest the FORTRAN crowd in such a language. Until then, FORGET it. And even then, learning the new language had better not take too much time out of these people's busy schedules. They have REAL work to do (pun intended). Only half :-) --alan@pdn
fpst@hubcap.UUCP (Steve Stevenson) (03/22/88)
in article <2596@pdn.UUCP>, alan@pdn.UUCP (Alan Lovejoy) says: > > Performance is an OBSESSION with these people. Perhaps rightly so in > some or even most cases. When Ada (Modula-2, C, C++, ML, Oberon, > whatever the latest and greatest language is...) compilers can > produce significantly faster code than FORTRAN compilers, > even when the full complement of abstraction mechanisms are used, > then you MIGHT be able to interest the FORTRAN crowd in such a language. > Until then, FORGET it. And even then, learning the new language had > better not take too much time out of these people's busy schedules. > They have REAL work to do (pun intended). > > Only half :-) > > --alan@pdn As a language person and a numerical analyst ( and being age > 40 :-) ) I think I can add something here. Go back to '57 and look at the situation. There were no higher level languages and the problems were all numerical. Then the comptrollers office found out about computers. The history of programming languages is a series of models which solve certain problems and present certain abstractions. The reason Fortran continues as a favorite has been mentioned in bits and pieces. But look at the abomination that F8X has foisted on us. Performance is an obsession because the size of the problems that are in front of the engineer and scientist today. *Prima facie*, that obsession is not bad. The problem with many languages today is that they address the *general* problem. All the funny business with arrays could be avoided if the standard shapes were incorporated in the language. I.e., settle on something - even SAXPY - as a model and build the language around that. -- Steve Stevenson fpst@hubcap.clemson.edu (aka D. E. Stevenson), fpst@clemson.csnet Department of Computer Science, comp.parallel Clemson University, Clemson, SC 29634-1906 (803)656-5880.mabell
beyer@houxs.UUCP (J.BEYER) (03/22/88)
The funny thing is that the CAS (Compare Accumulator with Storage) instruction was not used by the FORTRAN compiler for some reason. They used TZE and TPL or something like that. There were both positive and negative zeros because it was a sign-magnitude machine. Maybe this was in floating point as well (it's been a long time since I used a 704). -- Jean-David Beyer A.T.&T., Holmdel, New Jersey, 07733 houxs!beyer
davidsen@steinmetz.steinmetz.ge.com (William E. Davidsen Jr) (03/23/88)
The arithmetic if is one of the few good things in FORTRAN, and one I
miss in C every time I write some form of sort or tree search. There is
no clean way to do what the IF allows, ie. to make two conditional jumps
based on a single compare instruction. Yes, I know it's not a big
overhead in the scheme of things, but the IF is a representation of
something which you really want to do in useful programs.
Of course I wouldn't suggest having it be implemented as goto's, but
some reasonable syntax, such as:
evaluate (fun(4,"test") < 22)
{ < 0 action }
{ equal action }
{ > 0 action }
I am not really suggesting adding this to any language, but it allows
telling the compiler what you want in a way which allows generation of
good code.
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -mebzs@bu-cs.BU.EDU (Barry Shein) (03/23/88)
Yes, I agree that many FORTRAN users are obsessed with performance and some are good at getting it. Unfortunately many aren't, grad students in the sciences often have little training in programming and algorithms and issues like accuracy vs precision. More importantly they don't know what's important and often don't ask the right questions. I remember when I managed the Harvard Chemistry machine, for example, some very bright chemistry students had a routine for sorting a huge array of reals. It took something like 20 minutes and brought the 780 (this was several years ago) to its knees. I finally had a look at it, went across the street to the library, xeroxed the page from collected algorithms giving a quickersort for Fortran (I think it was quickersort, it's been a while), typed it in and reduced the run time to well under a minute, maybe 30 seconds. They had never heard of collected algorithms and were, needless to say, pleased with the results. There were other examples, when I worked with the pulmonary physiologists at Harvard I remember reducing the run-time of a routine that was run all day on hundreds of data sets from 20 minutes to about 20 seconds on a PDP-11. The programmers (medical physiologists) had bummed the code a lot but didn't realize what type conversions in the inner loop of a Hamming filter (convolution) was costing them, hoisting the code around a little yielded the speed-up. There's a lot more to it than good code-generators, I would tend to say that's the least of it. I still wonder why many of those folks who ran some of the intensive looping I saw ever thought they had anything more than bit-shift noise left in the resultant data, they didn't seem to understand the question when I asked and assumed the math in the machine behaved more or less as it should theoretically, they understood round-offs a little. I won't even talk about the folks who talked about the speed of running statistical routines but didn't seem to understand statistical design and would run test after test, whatever the hypotheses (hmm, the T-test didn't show anything, let's try a few F-ratios or ANOVAs and see if that works...) -Barry Shein, Boston University
eugene@pioneer.arpa (Eugene N. Miya) (03/23/88)
In article <2596@pdn.UUCP> alan@pdn.UUCP (0000-Alan Lovejoy) writes: > >The other reason is that FORTRAN programmers are interested in raw >performance above all else. . . . >numbers using 64-bit reals? They'll just make a copy of the one for >32-bit reals and use the editor's global replace to change the data >types as appropriate. Of course, all code is written for maximum >performance on the machine which will be used to run it. > >Performance is an OBSESSION with these people. I just came from a meeting (where several other comp.arch readers were present) where these issues were discussed as part of an evaluation of programming languages (not all functional) for high performance computing. Discussion was most interesting. Harry Jordan (a numerical methods person from the Univ. of Colorado] in some comparisons on functional languages, walked out of the room, was not willing to hear people who would not consider performance as an overriding feature of languages. Sure they have reasons for their obsessions: 1) Some of the science in these codes is an attempt to stand on the shoulders of colleagues and past science (read physics). We call them dusty decks some time. As an example we heard from an end user of powerful machines: 2) Jack Hack, an atmospheric physicist from NCAR [e.g., where or uuhosts -a hao] points out that weather is not just a 3-D problem. You just don't edit the constants in weather models, new variables emerge when you go to finer resolutions. This talk was interesting because it was one where all the computer people could relate (weather). David Kapholtz (Columbia) suggested there was a degree of arrogance in the not-to-be moved insistence on Fortran. Consider an example, not given by Hack: There are two kinds of value from a weather code: the predictive and the descriptive. A code which takes 27 hours run time to make a 24 hours forecast is bound to provoke snickers, but if the science is correct, then the descriptive value only needs minor tuning. The issue then is only performance (sorry, they are a bit short sighted since portability is a minor issue). The temptation to let compilers "do it all" [compiler overloading] with EXISTING languages is very high. So this gives Kuck Associates in Ill. and Kennedy at Rice lots of money. The computer community would otherwise have to band together to push new languages: [If you want new levels of performance, you are going to have to use XXX, where the Connection Machine or hypercubes are something of good examples (terrible to program, can you say 1946?)]. Your target has to be young researchers (physicists and others) who don't have vested interests in older existing codes. (See the work by Wolfram and other rogues of science.) This is why it is important in grad school to mingle at lunch with people outside your discipline (See Feynman's autobiography as an example of this). I bet you didn't see the relation between languages, architectures, and applications and having lunch with colleagues in other disciplines to understand their problems? ;-) Don't push it, but it is important. But, let's get back to architectures and why we build them. 8-) From the Rock of Ages Home for Retired Hackers: --eugene miya, NASA Ames Research Center, eugene@ames-aurora.ARPA "You trust the `reply' command with all those different mailers out there?" "Send mail, avoid follow-ups. If enough, I'll summarize." {uunet,hplabs,hao,ihnp4,decwrl,allegra,tektronix}!ames!aurora!eugene
eugene@pioneer.arpa (Eugene N. Miya) (03/23/88)
In article <10037@steinmetz.steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: > The arithmetic if is one of the few good things in FORTRAN, Arithmetic is FORTRAN is an abortion! No numerical analyst worth his (her) salt would truncate or specify user specified rounding (See the SIGPLAN paper entitled Benchmark Semantics a month ago). This is one of the reasons for the IEEE Floating Point Standard. These are kludges and other short cuts from the days when good floating point rounding "cost more." From the Rock of Ages Home for Retired Hackers: --eugene miya, NASA Ames Research Center, eugene@ames-aurora.ARPA "You trust the `reply' command with all those different mailers out there?" "Send mail, avoid follow-ups. If enough, I'll summarize." {uunet,hplabs,hao,ihnp4,decwrl,allegra,tektronix}!ames!aurora!eugene
zdenko@csd4.milw.wisc.edu (Zdenko Tomasic) (03/23/88)
In article <6328@ames.arpa> eugene@pioneer.UUCP (Eugene N. Miya) writes: >In article <10037@steinmetz.steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: >> The arithmetic if is one of the few good things in FORTRAN, > >Arithmetic is FORTRAN is an abortion! No numerical analyst worth his (her) ^^^^^^^^ shades of the Supreme Court decision, any verdict on ADATRAN ? :-) >salt would truncate or specify user specified rounding (See the SIGPLAN >paper entitled Benchmark Semantics a month ago). This is one of the reasons >for the IEEE Floating Point Standard. These are kludges and other short cuts ^^^^^^^^^^^^^^ >from the days when good floating point rounding "cost more." ^^^^^^^^^^^^^^ The arithmetic IF is not restricted to floating point, its is fine for integers. However you are right about FP, it is definitely very IFFY there. For very few cases arithmetic IF might be handy (i.e. all 3 branches are different), but in most cases it is awkward since it forces at least 2 labels to be used and gives a solid chance of writing a dead code. (It is a lot of fun to confuse a code reader, he/she has really nothing better to do or be amused with :-)). The first label following IF is really unnecessary if you believe in top-down approach, but the syntax mandates it. It is certainly very baroque, but how much code will break without it? (don't answer that!). > >From the Rock of Ages Home for Retired Hackers: > >--eugene miya, NASA Ames Research Center, eugene@ames-aurora.ARPA > "You trust the `reply' command with all those different mailers out there?" > "Send mail, avoid follow-ups. If enough, I'll summarize." > {uunet,hplabs,hao,ihnp4,decwrl,allegra,tektronix}!ames!aurora!eugene This discussion is extremely architectually relevant (IBM 70? :)), anybody working on arithmetic if machine? (very IFFy indeed). Zdenko Tomasic UWM, Chem. Dept. Milwaukee,WI,53201 __________________________________________________________ UUCP: ihnp4!uwmcsd1!csd4.milw.wisc.edu!zdenko ARPA: zdenko@csd4.milw.wisc.edu __________________________________________________________ Zdenko Tomasic UWM, Chem. Dept. Milwaukee,WI,53201 __________________________________________________________ UUCP: ihnp4!uwmcsd1!csd4.milw.wisc.edu!zdenko ARPA: zdenko@csd4.milw.wisc.edu __________________________________________________________
ok@quintus.UUCP (Richard A. O'Keefe) (03/23/88)
In article <10037@steinmetz.steinmetz.ge.com>, davidsen@steinmetz.steinmetz.ge.com (William E. Davidsen Jr) writes: > The arithmetic if is one of the few good things in FORTRAN ... > Of course I wouldn't suggest having it be implemented as goto's, but > some reasonable syntax, such as: > evaluate (fun(4,"test") < 22) > { < 0 action } > { equal action } > { > 0 action } What's wrong with typedef enum {LESS = -1, EQUAL = 0, GREATER = 1} Order; extern Order int_compare(int, int); switch (int_compare(fun(4,"test"), 22) { case LESS: ...; break; case EQUAL: ...; break; case GREATER: ...; break; } No new syntax needed. Where something like this pays off is when you are comparing strings or complicated records, and you don't want to do it twice, but that is when you are defining your own comparison function anyway. This is really a comp.lang.misc issue.
rwwetmore@watmath.waterloo.edu (Ross Wetmore) (03/23/88)
In article <6321@ames.arpa> eugene@pioneer.UUCP (Eugene N. Miya) writes: >In article <2596@pdn.UUCP> alan@pdn.UUCP (0000-Alan Lovejoy) writes: >> >>The other reason is that FORTRAN programmers are interested in raw >>performance above all else. . . . >> >>Performance is an OBSESSION with these people. > >Sure they have reasons for their obsessions: >1) Some of the science in these codes is an attempt to stand on the >shoulders of colleagues and past science (read physics). We call them >dusty decks some time. > >David Kapholtz (Columbia) suggested there was a degree of arrogance >in the not-to-be moved insistence on Fortran. > > ... but if the science is >correct, then the descriptive value only needs minor tuning. >The issue then is only performance (sorry, they are a bit short sighted >since portability is a minor issue). Ok, threshold exceeded ... my apologies if this turns out to be a mistake. I think this is an area where the classic symptoms of moral superiority abound. Computer science has progressed beyond the capabilities of Fortran and now views it with disdain as neanderthal. Scientists whose interest is not in computers themselves, but in the results they produce, are quite content to employ known and trusted tools if they do the job, and find it extremely frustrating when these tools are taken away and if at all replaced, then replaced with buggy new tools that are totally untrustworthy. Consider the following: 1) Scientists are paid to do science in their field, not computer science. Funding is based on production of tangible scientific results, not in upgrading software. 2) A scientists reputation is based on producing *correct* results. It is not possible to rewrite and test a 100,000 line package of code, nor is it possible to do this, on a timescale consistent with changes in computer technology. 3) Previous results and accumulated experience are used extensively in development and verification. Throwing this out is generally unthinkable. 4) Most significant packages in computational science have man-years of labour built into them, and are not simply screen-sized programs typical of many in computer science. 5) Unless there is a tangible benefit in performance or capability, rewrites are not ever desirable. It is not even desirable to waste the scientists time in learning a new machine environment unless there is some concrete advantage to be gained. 6) Few physicists, chemists or social scientists can appreciate (even if they wanted to) the benefits which are likely to come from new technology outside their area of expertise. They must be taught and shown remembering that what is obvious to the computer scientist is not likely to be so to the physicist, and there is always the chance that the computer scientist has missed something. What is really missing in all this is recognition by all parties that teaching and transporting technology from one discipline to another is both necessary and worthy of the time and expense. The second lesson is don't take away the tools of one discipline until you have upgraded them and the users to the next level. On the other side, time spent in learning new techniques is should not be considered as time wasted, and perhaps woudn't be if the learning process was facilitated and the benefits clearly visible. Ross W. Wetmore | rwwetmore@water.NetNorth University of Waterloo | rwwetmore@math.waterloo.edu Waterloo, Ontario N2L 3G1 | {clyde, ihnp4, ubc-vision, utcsri} (519) 885-1211 ext 3491 | !watmath!rwwetmore
dricej@drilex.UUCP (Craig Jackson) (03/24/88)
In article <25461@yale-celray.yale.UUCP> lisper-bjorn@CS.YALE.EDU (Bjorn Lisper) writes: >In article <2424@saturn.ucsc.edu> haynes@ucscc.UCSC.EDU (Jim Haynes) writes: >>We have to keep in mind that FORTRAN was originally designed to >>make it easier to program one architecture, the IBM 704 with up >>to 4K of 36-bit memory. I believe the whole idea of a language >>as a machine-independent way to program evolved later (correct/flame >>me if I'm wrong). So getting the machine-dependent features out >>of the language has been like pulling teeth. >I've been told that arithmetic IF in FORTRAN, IF (E) L1,L2,L3 where E is an >arithmetic expression and L1 - L3 are lines in the program to jump to >dependent on the sign of E, translated, except for the evaluation of E, to >one single instruction on that machine. >The instruction repertoire of old IBM machines also had an impact on other >"high-level" languages, like for instance LISP. CAR and CDR were apparently >the names of instructions to access left and right halfword, respectively, >on the IBM 7090. The CAR and CDR pointers were stored in halfwords in this >manner in this LISP system. I've long been fascinated with how the architecture of their first implementation affects languages. Many so-called machine-independent languages actually reflect quite a bit of the hardware available to their designers. For example, would Pascal have had packed & unpacked arrays if Wirth had been working on a byte-addressable machine, vs the word addressable CDC 6000? I suspect not. Also, would C have had the '++' & '--' operators had the underlying machine not had autoincrement & autodecrement? I think it might have, but certainly the addressing modes may have put ideas into Ritchie's head. A more definite example is the float == double assumption that runs through K&R C. On the PDP-11, it is extra work to switch the floating point unit between single and double precision. I'm certain that it was much easier just to leave everything in double. Can anybody else point to other examples of this? Are there any in Cobol or Ada, or other committee-designed languages? -- Craig Jackson UUCP: {harvard!axiom,linus!axiom,ll-xn}!drilex!dricej BIX: cjackson
cik@l.cc.purdue.edu (Herman Rubin) (03/24/88)
In article <800@cresswell.quintus.UUCP>, ok@quintus.UUCP (Richard A. O'Keefe) writes: > In article <10037@steinmetz.steinmetz.ge.com>, davidsen@steinmetz.steinmetz.ge.com (William E. Davidsen Jr) writes: || The arithmetic if is one of the few good things in FORTRAN > ... || Of course I wouldn't suggest having it be implemented as goto's, but || some reasonable syntax, such as: || evaluate (fun(4,"test") < 22) || { < 0 action } || { equal action } || { > 0 action } > > What's wrong with > typedef enum {LESS = -1, EQUAL = 0, GREATER = 1} Order; > extern Order int_compare(int, int); > > switch (int_compare(fun(4,"test"), 22) { > case LESS: ...; break; > case EQUAL: ...; break; > case GREATER: ...; break; > } > No new syntax needed. Where something like this pays off is when > you are comparing strings or complicated records, and you don't > want to do it twice, but that is when you are defining your own > comparison function anyway. This is really a comp.lang.misc issue. This is only acceptable if you are comparing _long_ strings or complicated records; it is far too costly otherwise. On the machines of the 50's, from which the language gurus seem to have gotten their ideas, testing and branching were cheap relative to computation; I fear that will never be the case again. Subroutine calls are expensive; even though int_compare (and is the problem only restricted to integers?) is not cheap, the subroutine call is likely to be even more costly. Few implementations allow the user to force inline. The mind of the mathematician can conceive far more than the compiler can fathom. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (ARPA or UUCP) or hrubin@purccvm.bitnet
anw@nott-cs.UUCP (03/24/88)
In article <2596@pdn.UUCP> alan@pdn.UUCP (0000-Alan Lovejoy) writes: > [...] When Ada (Modula-2, C, C++, ML, Oberon, > whatever the latest and greatest language is...) compilers can > produce significantly faster code than FORTRAN compilers, > [then users MIGHT switch ...] Many years ago, I ran the Whetstone benchmark through a collection of compilers on the University mainframe, then an ICL 1906A. The basic results were (in kilo-Whetstones per second): Pascal 661 [not my figure, no further info] Algol 68 628 [Malvern compiler, 1 pass, little optimisation] Fortran 585 [ICL optimising compiler, ? no checks] Algol 60 379 [ICL compiler] Algol 68 355 [as above, but with full checking] Fortran 282 [ICL non-optimising compiler] (Fuller details in the conference proceedings "Applications of Algol 68", Univ of E Anglia, March 1976.) I wasn't exactly overwhelmed by the hordes of engineers beating a path to my door, and wanting to know more about Algol 68 or Pascal. :-( -- Andy Walker, Maths Dept, Nott'm Univ. anw@maths.nott.ac.uk
kenny@uiucdcsb.cs.uiuc.edu (03/25/88)
/* Written 2:41 am Mar 23, 1988 by ok@quintus.UUCP in uiucdcsb:comp.arch */
What's wrong with
typedef enum {LESS = -1, EQUAL = 0, GREATER = 1} Order;
extern Order int_compare(int, int);
switch (int_compare(fun(4,"test"), 22) {
case LESS: ...; break;
case EQUAL: ...; break;
case GREATER: ...; break;
}
No new syntax needed. Where something like this pays off is when
you are comparing strings or complicated records, and you don't
want to do it twice, but that is when you are defining your own
comparison function anyway. This is really a comp.lang.misc issue.
/* End of text from uiucdcsb:comp.arch */
That baroque syntax isn't needed anyway. Any good optimizing
compiler with CSE elimination will pull the second test out of
{
register int result;
if ((result = fun (4, "test")) < 22) {stuff}
else if (result == 22) {stuff}
else /* result > 22 */ {stuff}
}
But, (and here's the gotcha), it isn't a very big win. One
compiler-writer of my acquaintance tried just that optimization,
remembering when the result of a comparison was already in the
condition codes, and threw the compiler at a collection of existing
application and benchmark programs. The only one on which he could
measure any speedup at all was a `fat pivot' quicksort.
Kevinnews@ism780c.UUCP (News system) (03/25/88)
In article <793@houxs.UUCP> beyer@houxs.UUCP (J.BEYER) writes: > > >The funny thing is that the CAS (Compare Accumulator with Storage) instruction >was not used by the FORTRAN compiler for some reason. They used TZE and TPL >or something like that. There were both positive and negative zeros because >it was a sign-magnitude machine. Maybe this was in floating point as well >(it's been a long time since I used a 704). > Actually the *compiler* did use CAS. But the programs it generated didn't use CAS :-). The reason that CAS was not generated is that FORTRAN (and FORTRAN II) did not have any compare operators. The only IF statement was the arithmetic if whose form is: IF ( <arithmetic-expression> ) <label-one>,<label-two>,<label-three> So in general there were no operands that could be compared. And yes, there were two forms for a floating zero. Also +0.0 was greater than -0.0 when compared with CAS. But fortunately, the difference between +0.0 and -0.0 did produce zero when tested with TZE (transfer on zero). One could speculate that the pecular behavior of CAS when comparing zeros is the reason that the comparsion operators and the logical-if were not in the original FORTRAN. But I personally suspect the reason is more mundane, no one thought of it. I last used a 704 in 1958, but I am producing this note based on the 704 reference manual that I have in front of me is I type. An intresting feature of the 704 and its sucessors (709, 7090, 7094, 7044) was that the accumulator was 2 bits wider than a word. Thus one could produce 4 overflows before any information was lost. There were some other interesting statements in the original FORTRAN that reflects the 704 archetecture. IF OVERFLOW tested (and reset) the sticky overflow indicator IF SENSE SWITCH tested operator controled switches SENSE LIGHT ON|OFF turned on (or off) lights on the operators console IF SENSE LIGHT tested the state of a sense light Marv Rubinstein -- Computer architecture historian
jlg@a.UUCP (Jim Giles) (03/25/88)
In article <17739@watmath.waterloo.edu>, rwwetmore@watmath.waterloo.edu (Ross Wetmore) writes: > I think this is an area where the classic symptoms of moral superiority > abound. Computer science has progressed beyond the capabilities of Fortran > and now views it with disdain as neanderthal. Scientists whose interest is > not in computers themselves, but in the results they produce, are quite > content to employ known and trusted tools if they do the job, and find it > extremely frustrating when these tools are taken away and if at all replaced, > then replaced with buggy new tools that are totally untrustworthy. Bravo! Not only that, the languages that computer scientists claim are so much more advanced often are not nearly as good as Fortran for the task of ordinary number-crunching. There is no a-priori reason that a language that was designed for compiler or operating system implementation should do scientific code as well as Fortran does. And, in fact, none do. J. Giles Los Alamos
jlg@a.UUCP (Jim Giles) (03/25/88)
In article <20821@bu-cs.BU.EDU>, bzs@bu-cs.BU.EDU (Barry Shein) writes: > > Yes, I agree that many FORTRAN users are obsessed with performance and > some are good at getting it. Unfortunately many aren't, grad students > in the sciences often have little training in programming and > algorithms and issues like accuracy vs precision. More importantly > they don't know what's important and often don't ask the right > questions. [... with specific examples] It's possible to write bad code in any language. If someone doesn't know about quicksort, he may write a very bad sort algorithm in Pascal, C, Ada, .... The fact that grad students don't know much about program- ming is NOT a reason to teach them C instead of Fortran. If their programming projects are full of scientific number-crunching, Fortran is the best language for the job. If they have trouble implementing efficient code, teach them programming - using whatever language that is suited to their work. J. Giles Los Alamos
cik@l.cc.purdue.edu (Herman Rubin) (03/25/88)
All of this discussion of FORTAN or C or PASCAL or whatever has nothing to do with comp.arch unless they directly reference features of the architecture which may dictate the use of procedures. The ones I have seen here are machine independent. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (ARPA or UUCP) or hrubin@purccvm.bitnet
meissner@xyzzy.UUCP (Usenet Administration) (03/25/88)
In article <515@drilex.UUCP> dricej@drilex.UUCP (Craig Jackson) writes: | I've long been fascinated with how the architecture of their first | implementation affects languages. Many so-called machine-independent | languages actually reflect quite a bit of the hardware available to their | designers. ... | Can anybody else point to other examples of this? Are there any in Cobol or | Ada, or other committee-designed languages? According to the History of Programming Languages, Cobol actually has a requirement in it that makes in mutually hard in all architectures of the day. The requirement is for 18 digit arithmetic, which was chosen because neither the decimal machines of the day or the binary machines could fit the value in a register, and thus would have an unfair advantage over the other. Of course, nowadays, you can fit 18 decimal digits in a 64 bit binary register (so does that make a Cray a good Cobol machine :-). -- Michael Meissner, Data General. Uucp: ...!mcnc!rti!xyzzy!meissner Arpa/Csnet: meissner@dg-rtp.DG.COM
perry@apollo.uucp (Jim Perry) (03/26/88)
> I think this is an area where the classic symptoms of moral superiority >abound. Computer science has progressed beyond the capabilities of Fortran >and now views it with disdain as neanderthal. ... Lots of good points >Ross W. Wetmore | rwwetmore@water.NetNorth What I find particularly amusing is that the people who are most vocal in their disdain of Fortran are very likely to be die-hard C programmers... Cro-Magnon perhaps? :-P Jim Perry perry@apollo.UUCP Apollo Computer, Chelmsford MA
jlg@a.UUCP (Jim Giles) (03/26/88)
In article <704@xyzzy.UUCP>, meissner@xyzzy.UUCP (Usenet Administration) writes: [...] > other. Of course, nowadays, you can fit 18 decimal digits in a 64 bit > binary register (so does that make a Cray a good Cobol machine :-). The Cray has proved amenable to all other languages that have been used on it. Why wouldn't it make a good Cobol machine? J. Giles Los Alamos P.S. O.K. the Cray Y-MP is not C-shaped. The TIME photo showed two curved bays on either side that I just assumed would meet in back to for the Cray C-shape we're so familiar with. I still like it - it has seats on the outboard power supplies (the ones for the IOS and the SSD). Supercomputers should be required to double as machine-room furniture!
urjlew@ecsvax.UUCP (Rostyk Lewyckyj) (03/26/88)
Since a mail reply to Mr. Walker in Great Britain is unlikely to be accepted by the gateway keepers, I am posting my comments. In article <551@tuck.nott-cs.UUCP>, anw@nott-cs.UUCP writes: > > Many years ago, I ran the Whetstone benchmark through a collection > of compilers on the University mainframe, then an ICL 1906A. The basic > results were (in kilo-Whetstones per second): > > Pascal 661 [not my figure, no further info] > Algol 68 628 [Malvern compiler, 1 pass, little optimisation] > Fortran 585 [ICL optimising compiler, ? no checks] > Algol 60 379 [ICL compiler] > Algol 68 355 [as above, but with full checking] > Fortran 282 [ICL non-optimising compiler] > > -- > Andy Walker, Maths Dept, Nott'm Univ. > anw@maths.nott.ac.uk Note that the Fortran compiler figure is the best of the figures for ICL compilers. Also did the machine you ran on have hardware floating point? My experience with Fortran on an ICL 1904 without floating point was that it was abysmal, while Cobol seemed to run just fine. I was surprised that an assignment A=B, or I=J was not simply load rhs followed by a store, but required some funny intervening manipulations. All this was back in 1974 so I can't dig out the details or tell you the version level of the compiler or operating system (George III). Anyway this should be being discussed in comp.lang.fortran. ----------------------------------------------- Reply-To: Rostyslaw Jarema Lewyckyj urjlew@ecsvax.UUCP , urjlew@tucc.bitnet or urjlew@tucc.tucc.edu (ARPA,SURA,NSF etc. internet) tel. (919)-962-9107
cdshaw@alberta.UUCP (Chris Shaw) (03/27/88)
Sorry about the time lag... too much work on the plate... In article <28200126@ccvaxa> aglew@ccvaxa.UUCP writes: > >..> Chris Shaw on SPARSPAK > >(1) Is it possible to give out your C-SPARSPAK? It isn't mine to give. You want to talk to Dr. J. Alan George at the U of Tenessee, or Oak Ridge N.L., or U of Waterloo (pick one, last I heard, he had some ceremonial position at Waterloo). Possible addresses: Mike Heath -> mth@ornl-msr Alan George -> jageorge@waterloo or jag@ornl-msr >(2) Do you have any ideas as to what a (vector) processor > can do to make sparse matrix codes run faster? Lisper's answer was basically right on this one. The subtlety that I don't think he mentioned is that sparse matrix code is basically a major exercise in data management. In other words, you squeeze out the zeros. This would be easy except that when you start the calculations, you cause some of these zeros to be filled in. So what you do is reserve space for all the fill-ins beforehand, then do the calculations. It's vectorizeable if you manage your data right, and you probably don't need scatter/gather. However, the verctors are likely to be short, which may not be such a win. -- Chris Shaw cdshaw@alberta.UUCP (via watmath, ihnp4 or ubc-vision) University of Alberta CatchPhrase: Bogus as HELL !
kelly@uxe.cso.uiuc.edu (03/28/88)
/* Written 9:15 pm Mar 24, 1988 by jlg@a.UUCP in uxe.cso.uiuc.edu:comp.arch */ In article <17739@watmath.waterloo.edu>, rwwetmore@watmath.waterloo.edu (Ross Wetmore) writes: > I think this is an area where the classic symptoms of moral superiority > abound. Computer science has progressed beyond the capabilities of Fortran > and now views it with disdain as neanderthal. Scientists whose interest is > not in computers themselves, but in the results they produce, are quite > content to employ known and trusted tools if they do the job, and find it > extremely frustrating when these tools are taken away and if at all replaced, > then replaced with buggy new tools that are totally untrustworthy. Bravo! Not only that, the languages that computer scientists claim are so much more advanced often are not nearly as good as Fortran for the task of ordinary number-crunching. There is no a-priori reason that a language that was designed for compiler or operating system implementation should do scientific code as well as Fortran does. And, in fact, none do. J. Giles Los Alamos /* End of text from uxe.cso.uiuc.edu:comp.arch */ I see a lot of people claiming that fortran is a wonderful number-crunching language. In my experience, even if this assertion has basis in fact, it is irrelevant to your average engineering (including myself) or scientist programmer. A well designed compiler will make a difference of about a factor of two in how fast a code runs. This difference between a so called good/bad programming language would not be more than 20%. The fact is your average engineering (including myself) or scientist programmer hasn't a clue how to write good fast code. And it is almost certain that any reasonably large code we write, can be made run at least 2 times faster by changing how it is coded. It is also true that for 99 percent of the code that we write, it doesn't matter how fast it runs, the most important aspect of the code is that it is maintainable. Now we get to our weather forcasting code, which predicts exactly what is going to happen in the next 24 hours but which takes 27 hours to run. When you go to optimize that code, it is much more important that the user can easily see what is going on in the code, than it be in the most efficient numerical programming language. If the person who is optimizing the code can see what calculations have to be carried out, then they have some chance at deciding on the most efficient algorithm for the job. Unfortunately, fortran has a habit of totally diguising the underlying algorithm. The reason scientists and engineers write programs in fortran is because we have been taught computer programming in fortran. This is sad, because learning another computer language really enhances one's programming ability. Good code can be written in any language, but one has to know another programming language in order to write good programs in fortran. My chief beef against fortran is that it is non portable. ANSI fortran is portable; but it is such a limited language, it has to be extended to make it useable for any large scale program. If you don't believe me, look at any large finite element code. All of them rely on extensions to fortran 77, extensions which in most cases are not portable. An addendum to the efficiency business: the author of a large commercial finite element code said to me once, "we rely on good optimizing compilers for performance". In my opinion this finite element code, is one of the most efficient available for the class of problems it solves. The reason it is so efficient is because the author selected the best algorithms available and not because of the efficiency of fortran as a number crunching language or because of the quality of the implementation.
fouts@orville.nas.nasa.gov (Marty Fouts) (03/29/88)
In article <17739@watmath.waterloo.edu> rwwetmore@watmath.waterloo.edu (Ross Wetmore) writes: > Consider the following: >1) Scientists are paid to do science in their field, not computer science. > Funding is based on production of tangible scientific results, not in > upgrading software. If your field is (say) Computational Fluid Dynamics, doesn't that make it a computational science? What I mean by this semifacetious remark is that if the science you are trying to do is a model of a physical phenomena, you are going to do a better job of it if you understand the limits and capabilities of modeling. Scientists have always been involved in making the tools they use. Much of mathematics was developed by scientists looking for ways to quantify their results. Current works in optics are being done by astronomers, trying to develop better telescopes, etc. In any field, the better you understand your tools, the better you can use thme. >2) A scientists reputation is based on producing *correct* results. It is > not possible to rewrite and test a 100,000 line package of code, nor is > it possible to do this, on a timescale consistent with changes in computer > technology. True, but many applications are not 100,000 line packages of code. Those scientists who mainly research new algorithms tend to work with much smaller codes. I have seen flow solvers that are only a few thousand lines of code, and we have people here who have translated programs between Fortran, C and Star-Lisp. >3) Previous results and accumulated experience are used extensively in > development and verification. Throwing this out is generally unthinkable. A mistake that can be made here is confusing experience with baggage. Sometimes you can throw the baggage away. Frequently you should throw it away. The experience of assembly language programming led to the development of high level languages. The baggage of assembly language programming (mostly) got thrown away. The same can be true of specific high level languages. >4) Most significant packages in computational science have man-years of > labour built into them, and are not simply screen-sized programs typical > of many in computer science. The problem with quantifiers like "most" are that there probably isn't any good research behind them. Some applications are short. Some are long and have a lot of support. The short ones are usually easy to translate into a new language. The long ones sometimes have large support organizations which can spend some of those man-years translating them into new languages, rather than supporting them in old languages. I would suppose that there are few long ones without support organizations which are of significant interest to the user community. >5) Unless there is a tangible benefit in performance or capability, rewrites > are not ever desirable. It is not even desirable to waste the scientists > time in learning a new machine environment unless there is some concrete > advantage to be gained. I agree. But where there is a benefit, it should be utilized. Also, rewrites don't have to be done by the scientist, they can be done by slave labor (er, graduate students) or by technical programmers. This requires a degree of cooperation and understanding not often achieved, but it might be very beneficial. >6) Few physicists, chemists or social scientists can appreciate (even if they > wanted to) the benefits which are likely to come from new technology > outside their area of expertise. They must be taught and shown remembering > that what is obvious to the computer scientist is not likely to be so to > the physicist, and there is always the chance that the computer scientist > has missed something. > I agree completely. It also works both ways. Few computer scientists have the time to become expert in other fields. Both sides need to recognize that because the other isn't expert in their area doesn't mean that they can not contribute. I have spent much of my career overcoming the assumption of engineers that I am a second class scientist because I *merely* do computers. > What is really missing in all this is recognition by all parties that >teaching and transporting technology from one discipline to another is both >necessary and worthy of the time and expense. The second lesson is don't take >away the tools of one discipline until you have upgraded them and the users >to the next level. On the other side, time spent in learning new techniques >is should not be considered as time wasted, and perhaps woudn't be if the >learning process was facilitated and the benefits clearly visible. > True, but the benefits are rarely visible in advance. This is the frustration of trying to produce them.
anw@nott-cs.UUCP (03/29/88)
In article <4816@ecsvax.UUCP> urjlew@ecsvax.UUCP (Rostyk Lewyckyj) writes: >Since a mail reply to Mr. Walker in Great Britain is unlikely >to be accepted [...]. Nottingham isn't exactly the remotest place in the universe! We do have intelligent life here, and an excellent cricket team. >In article <551@tuck.nott-cs.UUCP>, anw@nott-cs.UUCP writes: >> [ In response to a claim that Fortran addicts might change if the modern >> languages were more efficient, I quoted a Whetstone benchmark, showing >> that on an ICL 1906A in 1976 >> Pascal > Algol 68 > Fortran >> Algol 60 >> with little effect on the users. ] >Note that the Fortran compiler figure is the best of the figures >for ICL compilers. Yeah, third isn't bad. But note that the Algol 68 wasn't optimised, and the Fortran was. Good modern languages [1968 onwards!] allow the user to say what is wanted in a way that is easy to compile into efficient code. While I'm on the subject, a correspondent tells me of vague memories that Pascal and Algol also benchmarked faster than Fortran on the CDC 7600, again with very little effect on the general population of users. Rings a bell with me too -- anyone able to confirm or deny? > Also did the machine you ran on have hardware >floating point? Of course. '6A was top of the range. >Anyway this should be being discussed in comp.lang.fortran. I'd never dare admit to reading "comp.lang.fortran". But in deference to the minimal architecture content of these postings, I'm re-directing follow-ups to "comp.lang.misc". -- Andy Walker, Maths Dept, Nott'm Univ. anw@maths.nott.ac.uk
lamaster@ames.arpa (Hugh LaMaster) (03/30/88)
In article <46500011@uxe.cso.uiuc.edu> kelly@uxe.cso.uiuc.edu writes: >I see a lot of people claiming that fortran is a wonderful number-crunching >language. In my experience, even if this assertion has basis in fact, it is >irrelevant to your average engineering (including myself) or scientist >programmer. A well designed compiler will make a difference of about a >factor of two in how fast a code runs. This difference between a so called >good/bad programming language would not be more than 20%. Well, I don't know anybody who claims Fortran is "wonderful" - just better than the alternatives. Why? 1) Vectorizing compilers that can, in some cases, deliver performance on a vector machine (Cray, Cyber-205/ETA, etc.) of 50% of peak performance on a well designed code. That might be 100-200 MFLOPS, compared with 10 MFLOPS for a scalar version on the same machine. The payoff is much greater than the factor of two cited above. 2) Fortran is modular. Fortran subroutines are modules, and this puts Fortran ahead of any language (e.g. Pascal) which only has "procedures". Yes, both would be better. Unfortunately, I haven't seen any vectorizing Modula-2 compilers for the Cray or CDC machines. Convex does sport a vectorizing C compiler, however. 3) Fortran is not a bad programming language, even for systems programming. Fortran has been used as the basis for a number of system implementations. Now C bigots will note that C has modules and internal procedures, and, yes, it does have advantages as a system implementation languages. But, for a Fortran replacement it is hopeless. The syntax is confusing and more error prone than Fortran, but even worse, because C doesn't have dynamic array dimensioning you can't use it for separately compiled libraries like Linpack. > The fact is your average engineering (including myself) or scientist >programmer hasn't a clue how to write good fast code. And it is almost >certain that any reasonably large code we write, can be made run at least >2 times faster by changing how it is coded. It is also true that for >99 percent of the code that we write, it doesn't matter how fast it runs, Again, the payoff on a vector machine can be much more than a factor of two. True, it doesn't matter how fast most code runs. But it does matter how fast certain very important (to you, the user) codes run. And now that vector machines are reaching the market of below $100 K machines, you will have an opportunity to see which codes will run much faster. You may be pleasantly surprised. > My chief beef against fortran is that it is non portable. >ANSI fortran is portable; but it is such a limited language, it has >to be extended to make it useable for any large scale program. >If you don't believe me, look at any large finite element code. All >of them rely on extensions to fortran 77, extensions which in most >cases are not portable. Fortran is intrinsically neither more nor less portable than C. Thousands of Fortran programmers have run Linpack programs on their machines with no modifications. And thousands of C programmers continue to write code which depends on the existence of data types of certain sizes ( e.g. 16 bit ints), on machine dependencies such as byte order, and indeed on how the compiler will allocate the fields in a structure (just like the infamous Fortran equivalence!)...
lm@arizona.edu (Larry McVoy) (03/30/88)
In article <6630@ames.arpa> lamaster@ames.arc.nasa.gov.UUCP (Hugh LaMaster) writes: >2) Fortran is modular. Fortran subroutines are modules, and this puts >Fortran ahead of any language (e.g. Pascal) which only has "procedures". >Yes, both would be better. Unfortunately, I haven't seen any vectorizing >Modula-2 compilers for the Cray or CDC machines. Convex does sport a >vectorizing C compiler, however. Umm, I'll throw in a penny here: C has modules. Note that the following example defines an abstract data type, operations on the data type, but implies nothing about how the operations work, data storage, etc. (Actually, whomever makes "stack.h" defines the type, but that's a red herring.) So C gives you all of mod-2 with none of the pain. So what we need is a vectorizing C compiler, right? 1/2 :-) Seriously, please don't hold up Mod-2 as an example of a good programming language. Mod-2 sucks donkey noids is my experience after looking at big systems written in it. Here's the example, if anyone cares: ---- begin stack.c ------ /* * stack.c - dummy C module for netnews example */ # include "stack.h" /* defines stack_t */ # include <stdio.h> # define STACK_MAX 100 /* hidden */ static stack_t stack[STACK_MAX]; /* hidden */ static int indx = 0; /* hidden */ /* * push - push a copy of the item */ int push(s) stack_t s; { /* exported */ if (indx < STACK_MAX-1) { stack[++indx] = s; return 0; } return -1; } /* * pop - return a copy of the stack top, pop. */ stack_t pop() { static stack_t null; /* zero-ed for error return */ if (indx > 0) return stack[--indx]; return null; } ----- end stack.c ------ -- Larry McVoy lm@arizona.edu or ...!{uwvax,sun}!arizona.edu!lm
daveb@geac.UUCP (David Collier-Brown) (04/04/88)
In article <9545@ism780c.UUCP> marv@ism780.UUCP (Marvin Rubenstein) writes: >The reason that CAS was not generated is that FORTRAN (and FORTRAN II) did >not have any compare operators. The only IF statement was the arithmetic if >whose form is: > > IF ( <arithmetic-expression> ) <label-one>,<label-two>,<label-three> In some of the early proposal papers (FORTRAN 0), the if statemnent was if (expression comparison_operator expression) statement where both the expressions and operators were strongly restricted. The more general 3-valued if was actually implemented. -- David Collier-Brown. {mnetor yunexus utgpu}!geac!daveb Geac Computers International Inc., | Computer Science loses its 350 Steelcase Road,Markham, Ontario, | memory (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.
clewis@spectrix.UUCP (Chris Lewis) (04/08/88)
In article <6630@ames.arpa> lamaster@ames.arc.nasa.gov.UUCP (Hugh LaMaster) writes: Much as I hate FORTRAN, I will admit it has its uses. Particularly in number crunching. Mind you I believe that the main reason that FORTRAN is used so much for number crunching and is better than most others for number crunching is simply because it's used so much for number crunching. A circular argument ;-). But consider, since there is relatively little demand for SERIOUS number crunching in any other language, no other language-developer (eg: C or whatever) bothers to tune their language for it, nor is much in the way of mathematical libraries for anything else. Similar statement: IBM PC's or clones are better for running LOTUS than a Sun ["FORTRAN" is better for "NUMBER CRUNCHING" than "C"] Of course! Lotus doesn't run on a Sun.... [The only customers of ours doing number crunching use APL!] I wouldn't normally have said anything here, but I'm a little curious about some of your statements, and I would like you to clarify them. >2) Fortran is modular. Fortran subroutines are modules, and this puts >Fortran ahead of any language (e.g. Pascal) which only has "procedures". >Yes, both would be better. Unfortunately, I haven't seen any vectorizing >Modula-2 compilers for the Cray or CDC machines. Convex does sport a >vectorizing C compiler, however. What exactly do you mean by "modular"? Separate compilation and linking? Most "serious" languages have that - C, PL/1, Assembler, COBOL and (gasp) ADA to name a few (no flames about Ada being "serious" please :-). Most useable Pascal compilers (for big "systemy" things) do too (eg: IBM Pascal/VS), though this is of course not part of Wirth Pascal. It's been a while since I did any work with FORTRAN, but I think I can do just about everything FORTRAN can do with COMMONs and EQUIVALENTs in C. Simply because a language definition doesn't refer to "modules" doesn't mean that it doesn't have them. >3) Fortran is not a bad programming language, even for systems programming. As long as you wrap RATFOR around your FORTRAN :-) Seriously, speaking as an ex PL/1 and FORTRAN jock, it's been my experience that non-structured programs are hard to maintain. So hard in fact to often be impossible to maintain. Yes, I know that C can be written as spaghetti-like as FORTRAN can, but the language-training you get (from schools, books, courses whatever) *usually* leads a person into programming in more-or-less the same mind-set as everbody else. FORTRAN is usually spaghetti. C is usually not. [But there is a University around here that teaches FORTRAN IV programming style in PL/1 and C...] (Actually, RATFOR *is* pretty good for systemy stuff.) >Fortran has been used as the basis for a number of system implementations. >Now C bigots will note that C has modules and internal procedures, and, yes, I did. >it does have advantages as a system implementation languages. But, for a >Fortran replacement it is hopeless. The syntax is confusing and more error >prone than Fortran, This is of course open to debate. You can kill yourself with the ol' while(something); do something or a = sin(1); or if (a = b) something problems in C, but there's probably just as many in FORTRAN: DO I = 1 10 call f(2) subroutine f(a) a = 4 end problem (and a horde of others) in FORTRAN too (going back into the history of FORTRAN for my examples). At least, *most* of the versions of C will behave the same way to silly syntactical mistakes. FORTRAN does not. Yes, C programmers do sometimes depend on byte order and NULL-dereference behaviour. Most of the problems with USENET-distributed software is not due problems like this. They're mostly due to operating system differences (Xenix vs. BSD vs. SV vs. DOS), not language problems. Sure, Linpack will port real nice in FORTRAN - but try writing the netnews software (or any other multi-program, system-dependent thing like a mail system like I did) in FORTRAN. Then move it from an IBM MVS Fortran-H to a DEC VMS F77 environment. Or even just Fortran-G to H. Then you'll find out about FORTRAN incompatibility! Though, you're right. I wouldn't do major number crunching in C. Probably not FORTRAN either. (perl is the ticket! ;-) >but even worse, because C doesn't have dynamic array >dimensioning you can't use it for separately compiled libraries like >Linpack. Doesn't have dynamic array dimensioning? I will admit that using dynamic bounds multi-dimensional arrays is sometimes a bit hard, but dynamic length vectors is certainly no problem (the C libraries are chock full of routines that will handle variable-length vectors - eg the str* routines). And there's lots of libraries that will handle arrays of arbitrary objects (eg: qsort). And C can dynamically allocate storage - can FORTRAN? Can FORTRAN handle arbitrary numbers of dimensions? I don't think so. C can. Can FORTRAN handle complex data structures? Eg: dyamically allocated trees, linked lists etc.? "unions" (variant records)? Nope. Most versions of FORTRAN I've used can't even handle character data types for heck's sake (I stopped using FORTRAN just as F77 came out...). Mind you, the lack of dynamic length arrays as parameters is the single most important reason why I hate Pascal (I know some dialects support them, but not all) and some PL/1 subsets (eg: DRI PL/1G for CP/M...). Actually, if you think about it, I think C is more portable than FORTRAN when you compare the number of variants of FORTRAN (Fortran II, IV, 66, WATFOR, WATFIV, 77, SWATFIV and specialized versions from specific vendors (ala FORT-G, H, FORT-VS, F4+, F77 etc. etc. etc.) and C (which boils down to: pre-K&R V6, K&R-conformant (V7 and most others), and post-K&R - very little actually changed at all. Except for Intel processors. Sigh...) FORTRAN has changed a *lot* more over the years than C has. And those *really* old FORTRAN compilers are *still* around haunting us. -- Chris Lewis, Spectrix Microsystems Inc, UUCP: {uunet!mnetor, utcsri!utzoo, lsuc, yunexus}!spectrix!clewis Phone: (416)-474-1955