cole@silver.bacs.indiana.edu (Robert Cole) (11/22/88)
Does anyone have any experience with a Fortran to C language converter? I have a lot of faculty who are firmly entrenched in Fortran but would be willing to try to learn C with a little help in moving the volumes of old code they already have written. Please reply to: Robert Cole Indiana University cole@silver.bacs.indiana.edu cole@iubacs (bitnet) cole@gold.bacs.indiana.edu Thanks!
johnd@stellar.UUCP (John R. Dennis @stellar) (04/07/89)
Would some kind sole point me to a Fortran to C converter. I remember seeing at least one advertised in some trade rag. It may either be a commercial offering or a public domain version. The primary requirement is that it be capable of handling a LARGE body of fortran code (several hundred files comprising well over 100K lines of code). If you have any experience with such translators I would appreciate hearing your opinion. I don't normally subscribe to this news group, so if this is the 100th time this question has been asked I appologize. Thanks for you help!
johnd@stellar.UUCP (John R. Dennis @stellar) (04/07/89)
Sorry! my .signature was left off my previous posting of this article. Here it is again with the 'return address'. Would some kind sole point me to a Fortran to C converter. I remember seeing at least one advertised in some trade rag. It may either be a commercial offering or a public domain version. The primary requirement is that it be capable of handling a LARGE body of fortran code (several hundred files comprising well over 100K lines of code). If you have any experience with such translators I would appreciate hearing your opinion. I don't normally subscribe to this news group, so if this is the 100th time this question has been asked I appologize. Thanks for you help!
johnd@stellar.UUCP (John R. Dennis @stellar) (04/07/89)
Sorry, still having problems with our postnews software. Here is the return
address for the fortran to C converter question.
----------------------------------------------------------------------------
John Dennis
E Mail: johnd@Stellar.COM | {uunet,convex,decvax}!stellar!johnd
Snail Mail: Stellar Computer, 85 Wells Avenue Newton, MA 02159
Voice Mail: (617) 964-6228 x243dig@peritek.UUCP (Dave Gotwisner) (04/12/89)
In article <30359@stellar.UUCP>, johnd@stellar.UUCP (John R. Dennis @stellar) writes: > > Would some kind sole point me to a Fortran to C converter. I remember seeing > at least one advertised in some trade rag. It may either be a commercial > offering or a public domain version. The primary requirement is that it be > capable of handling a LARGE body of fortran code (several hundred files > comprising well over 100K lines of code). If you have any experience with such > translators I would appreciate hearing your opinion. I don't normally > subscribe to this news group, so if this is the 100th time this question has > been asked I appologize. Thanks for you help! Since I have responded to requests like this in the past, I figure I will post it this time, in case anyone else may need it in the future and read these groups. Green Hills Software, Inc. 425 East Colorado Street, Suite 710 Glendale, CA 91205 (818) 246-5555 FAX: 818-246-7037 has such a beastie. I don't know how good it is, but we use one of their other products (a 68K cross compiler running under VMS), and it is quite good. Binary copies can be gotten from: OASYS, Inc. 230 Second Ave. Waltham, MA 02154 617-890-7889 From the data sheet (product summary?) (a lot of this means nothing to me, I try to avoid Fortran): Language * ANSI Fortran-77 (Full language) * DoD Mil-STD 1753 * VAX/VMS Extensions * NAMELIST * Full Syntax OPEN * STRUCTURES * %VAL, %REF, %LOC * !comments * ENCODE/DECODE * INTEGER *1, *2 * Octal/Hex constants * etc. Optimizations * Register allocation * Strength reduction * Loop Invariant elimination * Common subexpressions * Value propagation * Tail recursion * Loop rotation * Static address elimination Hosts VAX/UNIX Sun-2 386 UNIX/DOS VAX/VMS Sun-3 (others by arrangement) If you want any more information, please contact either OASYS or Green Hills. Disclaimer: I do not work for either Green Hills or OASYS, and do not get any money (or credit, or anything else) if you should buy this product. I am posting this, just because it has been asked for several times in the past, and I had the sheet on my desk. -- ------------------------------------------------------------------------------ Dave Gotwisner UUCP: ...!unisoft!peritek!dig Peritek Corporation ...!vsi1!peritek!dig 5550 Redwood Road Oakland, CA 94619 Phone: 1-415-531-6500
t19@np1.hep.nl (Geert J v Oldenborgh) (04/12/89)
Just out of curiosity, how are (double) complex variables translated to C? This is the only stumbling block I have in converting freely back and forward. Geert Jan Van Oldenborgh t19@nikhefh.hep.nl
zdenko@csd4.milw.wisc.edu (Zdenko Tomasic) (04/12/89)
In article <158@np1.hep.nl> t19@np1.hep.nl (Geert J v Oldenborgh) writes: >Just out of curiosity, how are (double) complex variables translated to C? ^^^^^^^ as structures, of course BTW double complex is not standard f77 type Consider C++, since it can define them as objects being object-oriented language. >This is the only stumbling block I have in converting freely back and forward. ^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^ what about dynamic memory allocation (malloc)? -- ___________________________________________________________________ Zdenko Tomasic, UWM, Chem. Dept., P.O. Box 413, Milwaukee, WI 53201 UUCP: uwvax!uwmcsd1!uwmcsd4!zdenko ARPA: zdenko@csd4.milw.wisc.edu
jlg@lanl.gov (Jim Giles) (04/13/89)
From article <1992@csd4.milw.wisc.edu>, by zdenko@csd4.milw.wisc.edu (Zdenko Tomasic): > In article <158@np1.hep.nl> t19@np1.hep.nl (Geert J v Oldenborgh) writes: >>Just out of curiosity, how are (double) complex variables translated to C? > > Consider C++, since it can define them as objects being object-oriented > language. The problem with this is that all the primitive operations on 'objects' in C++ is done with procedure calls. So the translation of the following would contain two procedure call overheads: COMPLEX A,B,C ... A=B*C There would be a procedure call for each of the primitive operations (multiply and assignment). This is hardly what I have in mind when I use complex variables. Of course, there's nothing in the C++ definition that _requires_ that all functions be implemented externally. The problem is that the 'inlining' requires the source (or some intermediate form) of the function library to be present at compile time. This would mean (for example) that you couldn't market a package which implements COMPLEX as 'objects' without distributing the source. I've not heard that inlining is available on any C++ presently marketed. Actually, C++ 'objects' aren't really objects (as in SmallTalk et.al.), but the mechanism is really a restricted form of dynamic function overloading. Genuine function overloading is more general, easier to understand, and could be just as efficient.
turner@sdti.SDTI.COM (Prescott K. Turner) (04/13/89)
In article <11926@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >The problem with this is that all the primitive operations on 'objects' >in C++ is done with procedure calls. >... >I've not heard that inlining is available on any C++ presently marketed. Inlining is an explicit feature of C++ which is supported by AT&T's cfront and by the majority of marketed C++'s as they are based on cfront. Inlining is also supported by Zortech C++ and to the best of my knowledge by EVERY C++ presently marketed. >The problem is that the 'inlining' requires the source (or some >intermediate form) of the function library to be present at compile time. Compiling the user's code only requires the source of the procedures which are declared inline. A substantial C++ package is best off with only a small part of its code in the inline procedure definitions. A package need be distributed only with its header (INCLUDE) files. >Genuine function overloading is more general, easier to understand, and could >be just as efficient. Perhaps it "could be". But no other language surpasses C++ in availability and efficient support for dynamic overloading. -- Prescott K. Turner, Jr. Software Development Technologies, Inc. P.O. Box 366, Sudbury, MA 01776 USA (508) 443-5779 UUCP: ...{harvard,mit-eddie}!sdti!turner Internet: turner@sdti.sdti.com
scf@statware.UUCP (Steve Fullerton) (04/13/89)
In article <1992@csd4.milw.wisc.edu> zdenko@csd4.milw.wisc.edu (Zdenko Tomasic) writes: >In article <158@np1.hep.nl> t19@np1.hep.nl (Geert J v Oldenborgh) writes: >>Just out of curiosity, how are (double) complex variables translated to C? >Consider C++, since it can define them as objects being object-oriented >language. Cobalt Blue, a company out of San Jose has 2 FORTRAN-to-C translator products, FOR_C and FOR_C++. I have a copy of FOR_C and have seen demos of FOR_C++. If you need to deal with complex variables, then take a look at FOR_C++. The translation results in very readable code. FOR_C also handles complex but the resulting code might be best described as spaghetti, although it does a very nice job on other standard and non-standard FORTRAN. Their address and phone: Cobalt Blue 1683 Milroy, Suite 101 San Jose, CA 95124 408/723-0474 Just a satisfied customer. -- Steve Fullerton Statware, Inc. scf%statware.uucp@cs.orst.edu 260 SW Madison Ave, Suite 109 orstcs!statware!scf Corvallis, OR 97333 503/753-5382
henry@utzoo.uucp (Henry Spencer) (04/14/89)
In article <11926@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >...all the primitive operations on 'objects' >in C++ is done with procedure calls. So the translation of the following >would contain two procedure call overheads: > > COMPLEX A,B,C > ... > A=B*C > >... I've not heard that inlining is available on >any C++ presently marketed. In any sensible implementation of "complex" in any sensible C++ compiler, that code will get inlined, because the declarations of the = and * operators (in a .h file, usually) will contain the definitions and the compiler will therefore inline them. No procedure calls needed. Nobody would use C++ if everything required procedure calls, as is the case in all too many other object-oriented languages. C++ has a lot of warts; the ability to produce efficient code is what's won it so many friends in spite of its problems. If you want general inlining without having to carefully ask for it, that's harder, and it probably is true that existing compilers don't do it, for the same reason that most C and Fortran compilers don't: in the general case, it's hard. -- Welcome to Mars! Your | Henry Spencer at U of Toronto Zoology passport and visa, comrade? | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
jlg@lanl.gov (Jim Giles) (04/14/89)
From article <1989Apr13.173331.2116@utzoo.uucp>, by henry@utzoo.uucp (Henry Spencer): > In article <11926@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >> [...] >> COMPLEX A,B,C >> ... >> A=B*C >> >>... I've not heard that inlining is available on >>any C++ presently marketed. > > In any sensible implementation of "complex" in any sensible C++ compiler, ^^^^^^^^ > that code will get inlined, because the declarations of the = and * > operators (in a .h file, usually) will contain the definitions and the > compiler will therefore inline them. No procedure calls needed. I guess that makes the implementations I've seen in C++ documents not 'sensible'. In any case, the mechanism you describe (and any C++ mechanism) would require 7 different definitions for each operator: COMPLEX*INT, COMPLEX*FLOAT, COMPLEX*DOUBLE, COMPLEX*COMPLEX, INT*COMPLEX, FLOAT*COMPLEX, DOUBLE*COMPLEX. Or did you think that an implementation that _didn't_ support mixed mode operations was satisfactory? (This is, in fact, one of the problems with object oriented languages - they don't handle mixed mode operations very well. I recently added COMPLEX to a SmallTalk implementation. In order to do so, I had to modify the definitions of ALL the operators of ALL the other numeric data types so they would recognize when their other operand was COMPLEX.) By the way, mixed mode operations are a _very_ object oriented thing to want to do. COMPLEX is a subclass of NUMBER, just like FLOAT, INT, FRACTION, etc.. The primitive operators +, -, *, and / are defined on class NUMBER (even though separately implemented by each subclass). Therefore, all mixed mode operations should be expected to work. ----------------------------------------------------------------------- Consider the example again: COMPLEX A,B,C REAL X ... B=X A=B*C All the Fortrans I've ever used would recognize an optimization that I've not seen _any_ C++ compiler recognize: The multiply need only do 2 FLOAT multiplies, not 4 multiplies and 2 adds. The C++ code will blindly follow the definition of the operator (COMPLEX*COMPLEX) and will not notice that the imaginary part of B is guaranteed to be zero. Even if you solve the 'inlining' problem I mentioned in my last article, these problems of mixed mode and optimization make the C++ implementation less desireable.
henry@utzoo.uucp (Henry Spencer) (04/14/89)
In article <12000@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >... In any case, the mechanism you describe (and any C++ >mechanism) would require 7 different definitions for each operator: >COMPLEX*INT, COMPLEX*FLOAT, COMPLEX*DOUBLE, COMPLEX*COMPLEX, INT*COMPLEX, >FLOAT*COMPLEX, DOUBLE*COMPLEX. Or did you think that an implementation >that _didn't_ support mixed mode operations was satisfactory? ... Um, it may not have come to your attention that C++ will do conversions for you (given definition of suitable conversion operators). See pages 173-177 in Stroustrup's book; you have in fact hit on *precisely* the example he uses to explain why automatic application of user-defined conversions is a good thing. If that is not satisfactory, i.e. if you really do want all those operations to be different, you will of course need to specify them all no matter what you do. > COMPLEX A,B,C > REAL X > ... > B=X > A=B*C > >All the Fortrans I've ever used would recognize an optimization that >I've not seen _any_ C++ compiler recognize: The multiply need only >do 2 FLOAT multiplies, not 4 multiplies and 2 adds. The C++ code will >blindly follow the definition of the operator (COMPLEX*COMPLEX) and >will not notice that the imaginary part of B is guaranteed to be zero. >Even if you solve the 'inlining' problem I mentioned in my last article, >these problems of mixed mode and optimization make the C++ implementation >less desireable. Given in-header definitions of the operators, there is no reason why a C++ optimizing compiler can't do this. Existing C++ compilers, by and large, are not heavy optimizers; the language is too young for that yet. They will come. -- Welcome to Mars! Your | Henry Spencer at U of Toronto Zoology passport and visa, comrade? | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
gwyn@smoke.BRL.MIL (Doug Gwyn) (04/16/89)
In article <158@np1.hep.nl> t19@np1.hep.nl (Geert J v Oldenborgh) writes: >Just out of curiosity, how are (double) complex variables translated to C? >This is the only stumbling block I have in converting freely back and forward. Very likely a DOUBLE PRECISION COMPLEX datum is represented by what in C would be expressed as a structure: typedef struct { double re; double im; } dcomplex; Because of call-by-reference, when one of these data is passed as a subprogram argument the C equivalent would be to pass a pointer to the datum.
jlg@lanl.gov (Jim Giles) (04/18/89)
From article <1989Apr14.161147.28053@utzoo.uucp>, by henry@utzoo.uucp (Henry Spencer): > In article <12000@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >>... In any case, the mechanism you describe (and any C++ >>mechanism) would require 7 different definitions for each operator: >>COMPLEX*INT, COMPLEX*FLOAT, COMPLEX*DOUBLE, COMPLEX*COMPLEX, INT*COMPLEX, >>FLOAT*COMPLEX, DOUBLE*COMPLEX. Or did you think that an implementation >>that _didn't_ support mixed mode operations was satisfactory? ... > > Um, it may not have come to your attention that C++ will do conversions That's exactly what I DON'T want it to do. Converting to complex before the operation eliminates exactly the sort of optimization that should ALLWAYS be done. (And, yes, I know Stroustrup recommends conversion here - he also implements COMPLEX as two DOUBLES (bad choice), and he only implements mixed mode operators fo COMPLEX*DOUBLE combinations.) > [...] If that is not satisfactory, i.e. if you > really do want all those operations to be different, you will of course > need to specify them all no matter what you do. Not necessarily. The syntax I would recommend would allow declaration of ALL the mixed mode for a given operator in _one_ declaration: Class ordinary_number:: (integer, float) Commutative infix operator '*' is Inline complex function mixed_mult (complex::x, ordinary_number::y) mixed_mult.real = x.real * y mixed_mult.imag = x.imag end This syntax is Fortran-like (what about it for Fortran++ :-). Because of the Class definition (which doesn't mean the same thing as a object oriented language class), the function is generic for integers and floats in its second argument. It is declared explicitly to be INLINE. And, since the operator is declared to be commutative, the function is invoked no matter which order the operands appear in the expression. This stands for four separate declarations in C++ (all of which have the same internal definition - the two assignment statements). > [...] > Given in-header definitions of the operators, there is no reason why a > C++ optimizing compiler can't do this. Existing C++ compilers, by and > large, are not heavy optimizers; the language is too young for that yet. > They will come. The optimization I had in mind is called constant folding. It was first applied in compilers in the late fifties. The technology involved in providing this optimization is therefore older than most C++ programmers are. If a compiler still doesn't have it, it is because some other problem is involved. In the case of the C++ environment I have access to, the problem is that new operators are not inline. Presumably those C++ processors that do inlining also do this constant folding operation (I hope!).
rob@akela.eng.ohio-state.edu (Rob Carriere) (04/18/89)
In article <12169@lanl.gov> jlg@lanl.gov (Jim Giles) writes: } Class ordinary_number:: (integer, float) } } Commutative infix operator '*' is } Inline complex function mixed_mult (complex::x, ordinary_number::y) } mixed_mult.real = x.real * y } mixed_mult.imag = x.imag **** * y /* I hope ?! */ } end SR 2*i == 2i
jlg@lanl.gov (Jim Giles) (04/18/89)
From article <1946@quanta.eng.ohio-state.edu>, by rob@akela.eng.ohio-state.edu (Rob Carriere): > In article <12169@lanl.gov> jlg@lanl.gov (Jim Giles) writes: > } [...] > } mixed_mult.imag = x.imag > **** * y /* I hope ?! */ OOPS! Quite right. Serves me right for typing stuff before coffee in the morning. . . .
diamond@diamond.csl.sony.junet (Norman Diamond) (04/18/89)
In article <12169@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >(And, yes, I know Stroustrup recommends >conversion here - he also implements COMPLEX as two DOUBLES (bad choice), >and he only implements mixed mode operators fo COMPLEX*DOUBLE combinations.) Perhaps the idiotic question should come first. Why are two doubles a bad choice? If arbitrary-precision-rationals are available, then of course a complex should be two arbitrary-precision-rationals (unless that would also be a bad choice!...why); otherwise, what is wrong with two doubles? >The syntax I would recommend would allow declaration of >ALL the mixed mode for a given operator in _one_ declaration: > > Class ordinary_number:: (integer, float) > > Commutative infix operator '*' is > Inline complex function mixed_mult (complex::x, ordinary_number::y) > mixed_mult.real = x.real * y > mixed_mult.imag = x.imag > end > >This syntax is Fortran-like (what about it for Fortran++ :-). Looks Ada-like to me. I only see one line there that a Fortran compiler would be happy with. Anyway, here's what's wrong with folding too many declarations into one, with this kind of syntax: Multiplication of complexes is commutative, but multiplication of matrices is not. Multiplication of complexes and multiplication of matrices are both associative (which you forgot to mention). Addition of complexes is commutative but addition of strings is not. (Addition of strings, a popular feature in recent languages, should have been multiplication instead, but that would be Not Invented Here.) Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.jp@relay.cs.net) The above opinions are my own. | Why are programmers criticized for If they're also your opinions, | re-inventing the wheel, when car you're infringing my copyright. | manufacturers are praised for it?
jlg@lanl.gov (Jim Giles) (04/19/89)
From article <10176@socslgw.csl.sony.JUNET>, by diamond@diamond.csl.sony.junet (Norman Diamond): > [...] > Perhaps the idiotic question should come first. Why are two doubles a > bad choice? [...] Two doubles are a bad choice because it's inefficient to do it that way. On the Cray, doubles have 28 digits of precision, but it takes 50 (that's right - FIFTY) time as long to compute with doubles as with singles. That doesn't even include the fact that doubles don't vectorize! Single precision carries 14 digits of precision and is adequate for most computation. The use of double should be for very rare cases in which single precision isn't sufficient. > [...] >> Class ordinary_number:: (integer, float) >> >> Commutative infix operator '*' is >> Inline complex function mixed_mult (complex::x, ordinary_number::y) >> mixed_mult.real = x.real * y >> mixed_mult.imag = x.imag[* y !To fix previous error] >> end > > Looks Ada-like to me. I only see one line there that a Fortran compiler > would be happy with. [...] Look at the Fortran 8x document. This syntax is similar to that in the proposed standard (the differences are deliberate). > [...] Anyway, here's what's wrong with folding too many > declarations into one, with this kind of syntax: > > Multiplication of complexes is commutative, but multiplication of > matrices is not. [...] SO WHAT! The declaration above doesn't even mention matrices. Since the whole idea of operator overloading is to provide for different definitions of the operators for different argument types, I can define multiplication on matrices (if I define such a type) later. Anyway, the operator as declared here, is already perfectly acceptable as an element-wise array operator (just like the other scalar operators are). Complex is, of course, a _scalar_ data type (as far as the programming language is concerned). > [...] Multiplication of complexes and multiplication of > matrices are both associative (which you forgot to mention). I deliberately left the ASSOCIATIVE attribute out since I didn't want to clutter the example. Anyway, the associative attribute is only useful if the compiler (or preprocessor) is capable of using it to optimize expressions involving user-overloaded operators - something C++ cannot do yet either. > Addition of complexes is commutative but addition of strings is not. > (Addition of strings, a popular feature in recent languages, should > have been multiplication instead, but that would be Not Invented Here.) Again, this doesn't have anything to do with the example given. As for the NIH syndrome (Not Invented Here), I can only say that it can be correctly applied as a derogatory phrase if (and only if) the proposed functionality is already readily available elsewhere. It isn't in this case.
henry@utzoo.uucp (Henry Spencer) (04/25/89)
In article <12247@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >On the Cray, doubles have 28 digits of precision, but it takes 50 (that's >right - FIFTY) time as long to compute with doubles as with singles. That >doesn't even include the fact that doubles don't vectorize! Single precision >carries 14 digits of precision and is adequate for most computation. The >use of double should be for very rare cases in which single precision isn't >sufficient. Given the pervasive nature of double in C code, sounds like Cray made a bad decision (or an interim one). The right way to do this is to make float and double synonymous (which is legal) and use ANSI C's "long double" for the super-precise type. -- Mars in 1980s: USSR, 2 tries, | Henry Spencer at U of Toronto Zoology 2 failures; USA, 0 tries. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
dik@cwi.nl (Dik T. Winter) (04/25/89)
In article <1989Apr24.172747.993@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: > In article <12247@lanl.gov> jlg@lanl.gov (Jim Giles) writes: > >On the Cray, doubles have 28 digits of precision, but it takes 50 (that's > >right - FIFTY) time as long to compute with doubles as with singles. That > >doesn't even include the fact that doubles don't vectorize! Single precision > >carries 14 digits of precision and is adequate for most computation. > > Given the pervasive nature of double in C code, sounds like Cray made a bad > decision (or an interim one). Given that Cray's choice predates C, this sounds a bit strange. Considering K&R and Ansi C, I would say that K&R made a bad decision (and clearly an interim one). -- dik t. winter, cwi, amsterdam, nederland INTERNET : dik@cwi.nl BITNET/EARN: dik@mcvax
gwyn@smoke.BRL.MIL (Doug Gwyn) (04/25/89)
In article <8050@boring.cwi.nl> dik@cwi.nl (Dik T. Winter) writes: -In article <1989Apr24.172747.993@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: - > In article <12247@lanl.gov> jlg@lanl.gov (Jim Giles) writes: - > >On the Cray, doubles have 28 digits of precision, but it takes 50 (that's - > >right - FIFTY) time as long to compute with doubles as with singles. That - > >doesn't even include the fact that doubles don't vectorize! Single precision - > >carries 14 digits of precision and is adequate for most computation. - > Given the pervasive nature of double in C code, sounds like Cray made a bad - > decision (or an interim one). -Given that Cray's choice predates C, this sounds a bit strange. Considering -K&R and Ansi C, I would say that K&R made a bad decision (and clearly an -interim one). That's completely wrong -- C predates Cray Inc. and in any case the Cray implementor of C was free to choose either the 14-digit or the 28-digit precision to represent C "double" type. If Giles's description of the relative tradeoffs is correct, then I would agree that a bad choice was made. In an ANSI C implementation on such a computer, the new "long double" type would be a good match for the 28-digit precision type. I would still advise using the 14-digit representation for doubles.
peter@ficc.uu.net (Peter da Silva) (04/25/89)
In article <8050@boring.cwi.nl>, dik@cwi.nl (Dik T. Winter) writes: > Given that Cray's choice predates C, this sounds a bit strange. Wait a second. I thought Cray was still at CDC in '70. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
karl@haddock.ima.isc.com (Karl Heuer) (04/26/89)
In article <8050@boring.cwi.nl> dik@cwi.nl (Dik T. Winter) writes: >In article <1989Apr24.172747.993@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >>In article <12247@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >>>[Cray's double is inefficient] >>Given the pervasive nature of double in C code, sounds like Cray made a bad >>decision (or an interim one). > >Given that Cray's choice predates C, this sounds a bit strange. No, Henry's right. Given the above information, it does appear that Cray (here taken to mean the persons who designed the C compiler for that machine) made a bad decision. Assuming they have only two floating-point sizes, they should have mapped the C type `double' to the smaller one, and used `long double' for the less efficient type. I also hold the opinion that K and R made some bad decisions with float and double, some of which are fixed by ANSI C, but this doesn't contradict the above paragraph. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
dik@cwi.nl (Dik T. Winter) (04/26/89)
In article <10112@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: > In article <8050@boring.cwi.nl> dik@cwi.nl (Dik T. Winter) writes: > -Given that Cray's choice predates C, this sounds a bit strange. Considering > -K&R and Ansi C, I would say that K&R made a bad decision (and clearly an > -interim one). > > That's completely wrong -- C predates Cray Inc. That is right, but I said something else: Cray's choice predates C; you know, you will find Seymour Cray's choice in such relicts as the CDC 7600. (Yup, all older, 60-bit, Cybers have 60-bit single precision floating point, and nothing smaller.) -- dik t. winter, cwi, amsterdam, nederland INTERNET : dik@cwi.nl BITNET/EARN: dik@mcvax
jlg@lanl.gov (Jim Giles) (04/26/89)
From article <12787@haddock.ima.isc.com>, by karl@haddock.ima.isc.com (Karl Heuer): > [...] Assuming they have only two floating-point sizes, they > should have mapped the C type `double' to the smaller one, and used `long > double' for the less efficient type. Actually, I think that this is what Cray's C compiler actually does: it implements both "float" and "double" as the default 64-bit hardware floats - and there _is_no_other_precision_. This, of course is almost as bad as the description I gave in my original posting. In any case, with respect to the original subject, whichever way Cray did it: C is not yet capable of adequately replacing Fortran (I doubt that it ever will be). By the way, what _is_ "long double"? I've never seen a C compiler which has such a thing. The proposed ANSI standard mentions "long double", but doesn't require it to be more precise than double! In fact, the only surprising thing about floating point in the standard is that it requires the FLT_RADIX to be 2 - that is, it requires "float" to be binary! No radix is defined for "double" or "long double".
john@frog.UUCP (John Woods) (04/26/89)
In article <8050@boring.cwi.nl>, dik@cwi.nl (Dik T. Winter) writes: > In article <1989Apr24.172747.993@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: > > In article <12247@lanl.gov> jlg@lanl.gov (Jim Giles) writes: > > >On the Cray, doubles have 28 digits of precision, but it takes 50 (that's > > >right - FIFTY) time as long to compute with doubles as with singles. > > Given the pervasive nature of double in C code, sounds like Cray made a bad > > decision (or an interim one). > Given that Cray's choice predates C, this sounds a bit strange. Considering > K&R and Ansi C, I would say that K&R made a bad decision (and clearly an > interim one). Cray made a bad choice of assigning the longer format to the "double" keyword. Having "float" and "double" be identical is a perfectly valid C implementation (as Henry said). K&R made a mathematician's choice, not the choice of FORTRAN jocks who have gotten used to the vagaries of hardware and who have made a virtue of hardship :-). -- John Woods, Charles River Data Systems, Framingham MA, (508) 626-1101 ...!decvax!frog!john, john@frog.UUCP, ...!mit-eddie!jfw, jfw@eddie.mit.edu
jlg@lanl.gov (Jim Giles) (04/26/89)
From article <12661@lanl.gov>, by jlg@lanl.gov (Jim Giles): > [...] In fact, the > only surprising thing about floating point in the standard is that > it requires the FLT_RADIX to be 2 - that is, it requires "float" to > be binary! No radix is defined for "double" or "long double". My mistake! Another part of the standard says that FLT_RADIX applies to all three floating point types. So, C requires floating point to be binary. This is a departure from ANSI programming languages in the past.
dmr@alice.UUCP (04/26/89)
This newsgroup has become very silly lately, rather like the end of a Python sketch. Giles stated, "On the Cray, doubles have 28 digits of precision, but it takes 50 (that's right - FIFTY) time as long to compute with doubles as with singles," which is incorrect for the Cray C compiler. Actually, with Cray's C, everything but chars is 64 bits. Giles may have confused C with Fortran. The CFT compiler needs an option to make doubleprecision 64 rather than 128 bits, but the C compilers don't, and don't seem to have the opposite option. Speaking of doubleprecision, the next topic of discussion is why C believes in whitespace. Dennis Ritchie
gwyn@smoke.BRL.MIL (Doug Gwyn) (04/26/89)
In article <12661@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >By the way, what _is_ "long double"? I've never seen a C compiler which >has such a thing. We could have guessed that from the tone of your earlier remarks. >The proposed ANSI standard mentions "long double", but doesn't require >it to be more precise than double! That's correct; it doesn't require double to be more precise than float, either, although the MINIMUM number of digits of significance REQUIRED for both double and long double is greater than for float, and each "larger" type is required to be able to express a (not necessarily proper) superset of the values of the "smaller" types. The exact rationale for the particular requirements of the Standard is fairly lengthy, but basically the Standard guarantees what was considered to be minimum acceptable accuracy without forcing too many implementations into software emulation. Implementations that have hardware support for very long floating-point are advised to map long double onto that, but so long as the requirements of the Standard are met, such details are a matter of quality of implementation and are therefore left up to the marketplace to determine. >In fact, the only surprising thing about floating point in the standard >is that it requires the FLT_RADIX to be 2 - that is, it requires "float" >to be binary! No radix is defined for "double" or "long double". You cannot have read the Standard very carefully. FLT_RADIX applies to all three floating types. Also, FLT_RADIX is required to be AT LEAST 2, not PRECISELY 2. Furthermore, the implementation does not have to adhere exactly to the particular (Fortran-inspired) model used in Section 2.2.4.2 of the Standard; for example, it could use variable-width encodings. The minima required for Standard conformance are to be taken in strict accordance with the given model, and the implementation definition of the macros upon inclusion of <float.h> is intended to be a guarantee of minimum precision, etc.; however, the implementation is allowed to be arbitrarily better than described by <float.h>. It is in an implementor's best interests to make his <float.h> indicate as much guaranteed precision and exponent range as is feasible. P.S. This is not an official X3J11 interpretation. For that, send a query to X3J11 via CBEMA X3.
bph@buengc.BU.EDU (Blair P. Houghton) (04/26/89)
In article <9244@alice.UUCP> dmr@alice.UUCP writes: >This newsgroup has become very silly lately, rather like the end of a >Python sketch. It's 8:10 a.m., and time for the critter->penguin on top of your t.v.set to explode = (void *) "fwooosh!"; >Speaking of doubleprecision, the next topic of discussion is why C >believes in whitespace. I'd make a crude crack about "master race" and "disgruntlement after the reparations of WWI", but there are a few anniversaries pending that make my anti-nazi blood boil a little hot, so no humor involving the scourge of human history today, okay. >:-| Actually, metaphysically, C doesn't believe in whitespace, given that good ol' Max. Munch knows how to do his job well without all the cbeautify or Indian Hills traditions, discarding them in the same manner that I discard unsolicited pleas to "let Jesus/Vishnu/Rama/ Islam/The Larch/Odin/Buddha in." , Tres plus, no two kiddies ever place the same blanety-blanks in the same (expletive deleted) places, and the fundamental tenet of the annual Obfuscated C Code Contest is that 'whitespace wastes bytes that could be better used for camouflage and indirection,' so, parapsychologically, neither do the rest of the world of C programmers believe in 'the one, true C style' of redistribution of the nonentities. What I'm trying to say is, is this going to (ohpleasegodnoI'llbedamn goodjustdon'tletithappenagain) reopen the [rd]e{bate,hash} surrounding everybody's favorite arrangement of negligible pseudotokens? I mean, if I have to waste the three nanoergs it takes to hit 'k' every time that thread comes around, I'm going to start charging consulting rates... --Blair "...and, with my ego, that could run into $_millards_..."
jlg@lanl.gov (Jim Giles) (04/27/89)
From article <9244@alice.UUCP>, by dmr@alice.UUCP: > Actually, with Cray's C, everything but chars is 64 bits. Giles may > have confused C with Fortran. The CFT compiler needs an option to make > doubleprecision 64 rather than 128 bits, but the C compilers don't, > and don't seem to have the opposite option. As I pointed out in my most recent submission on this thread. As I also pointed out, the actual C implementation is no better than the one I originally described. Single and double should be two _different_ types and Complex should (at least by default) be single. > Speaking of doubleprecision, the next topic of discussion is why C > believes in whitespace. Yes. For example, why does C treat a carriage return as whitespace? Nobody programs like that. Most people put _one_ statement per line, so the use of _both_ semicolon and carriage return as statement terminators seems redundant. Why does C choose to ignore the "wrong" one? > Dennis Ritchie And, of course, THANKS. Now I can claim to have been actually flamed by Dennis Ritchie HIMSELF on _two_ occasions! 8-)
bobmon@iuvax.cs.indiana.edu (RAMontante) (04/27/89)
->Speaking of doubleprecision, the next topic of discussion is why C ->believes in whitespace. C doesn't HAVE to _believe_ in whitespace; the existence of whitespace is easily _proven_ by inspecting printouts. (This may fail on ADM-3's and similar terminals, especially the ones that power-up with CAPS LOCK set ON.) If all C files go through the preprocessor first, does the code generator have to believe in stdio.h? Is the linker agnostic? "Our R-tchie Who Art in Bell Labs, External static be Thy Name. Thy system call come, I/O be done, In industry as it is in academia."
bobmon@iuvax.cs.indiana.edu (RAMontante) (04/27/89)
jlg@lanl.gov (Jim Giles) <12716@lanl.gov> :
-
-Yes. For example, why does C treat a carriage return as whitespace?
-Nobody programs like that. Most people put _one_ statement per line,
You've just convinced me that you don't know what you're talking about.
The number of statements per line is just an incidental artifact. If people thought their statements ended at the carriage return, you'd either have BASIC's notion of a namespace, or lines that look like this.
I used to know FORTRAN programmers who programmed like this; they also
generated spaghetti code routinely, stopped dead in column 72, had never met
the concept of indentation, and thought that whitespace was unManly.
I often put one statement per line when I program in C, because I often
write trivial programs. But if I have to indent things to any extent, or
use descriptive names, or call a subroutine that has a number of
arguments... I have to indent. To say nothing of compound statements, like
for (z_axis = 0; z_axis < MAX_z; z++)
{
/*
* 32 lines of operations...
*/
} /* end of _one_ compound statement */
-so the use of _both_ semicolon and carriage return as statement terminators
-seems redundant. Why does C choose to ignore the "wrong" one?
Just what exactly do you think is the "wrong" statement terminator here?
-And, of course, THANKS. Now I can claim to have been actually flamed by
-Dennis Ritchie HIMSELF on _two_ occasions! 8-)
And now you've been flamed from the other end of the spectrum :-)corbett@beatnix.UUCP (Bob Corbett) (04/27/89)
In article <8050@boring.cwi.nl> dik@cwi.nl (Dik T. Winter) writes: ->In article <1989Apr24.172747.993@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: -> > In article <12247@lanl.gov> jlg@lanl.gov (Jim Giles) writes: -> > >On the Cray, doubles have 28 digits of precision, but it takes 50 (that's -> > >right - FIFTY) time as long to compute with doubles as with singles. That -> > >doesn't even include the fact that doubles don't vectorize! Single precision -> > >carries 14 digits of precision and is adequate for most computation. -> > -> > Given the pervasive nature of double in C code, sounds like Cray made a bad -> > decision (or an interim one). -> ->Given that Cray's choice predates C, this sounds a bit strange. Considering ->K&R and Ansi C, I would say that K&R made a bad decision (and clearly an ->interim one). ->-- ->dik t. winter, cwi, amsterdam, nederland ->INTERNET : dik@cwi.nl ->BITNET/EARN: dik@mcvax C was designed in 1972. The earliest shipment of a Cray-1 that I have been able to verify occurred in 1976. In 1972, Cray (the man, not the company) was designing the CDC 8600. Faithfully yours, Robert Paul Corbett
gwyn@smoke.BRL.MIL (Doug Gwyn) (04/27/89)
In article <12716@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >Yes. For example, why does C treat a carriage return as whitespace? >Nobody programs like that. Most people put _one_ statement per line, >so the use of _both_ semicolon and carriage return as statement terminators >seems redundant. Why does C choose to ignore the "wrong" one? I'll choose to treat this as an honest request for information.. I'll also assume you're taking about new-lines, not strictly CRs. Many programming environments work best when source file line lengths are limited, typically to no more than 80 characters (the exact useful limit varies). There are many instances in C coding when the natural expression of a simple statement (not talking about entire loops, etc., but rather things like expression statements) simply does not fit on a single line within such a length limit. This especially happens when 8-column tab stops are involved (which often is the best-supported or ONLY supported tab spacing), but it would occur even if one started every statement in the first position of a line. Therefore, allowing simple statements to span multiple lines is a practical convenience for the programmer. RatFor is an example of a language that attempted to support line spanning while simultaneously treating new-line as a statement terminator most of the time. It worked okay but was rather ad-hocish; a uniform simple rule such as C has seems better to me.
mat@mole-end.UUCP (Mark A Terribile) (04/27/89)
> This newsgroup has become very silly lately, rather like the end of a > Python sketch. I second the assertion. Dare I remind people what netnews old-timers should already know: Always expect abandonment of inhibition. > Speaking of doubleprecision, the next topic of discussion is why C > believes in whitespace. > > Dennis Ritchie If I may be permitted to criticize the distinguished author, it might have been wiser not to suggest the topic! C resembles a block of knives, each one tempered, shaped, ground, and sharpened to do a particular job. Some of the (like the comma op) are mean for special details, like the knives used to get the last bit of flesh off a bone. If such knives are used in other roles, they will not cut well, will dull rapidly or break, and will generally raise the risks to both the job and the people doing it. That doesn't mean that such knives don't belong in the block, nor does the presence of a given knife in the block constitute a blanket recommendation of that knife for all jobs. ANSI C gives us plenty of good stuff to talk about. Let's keep this a technical group so that it doesn't wind up as talk.c-freaks . -- (This man's opinions are his own.) From mole-end Mark Terribile
jlg@lanl.gov (Jim Giles) (04/28/89)
From article <10134@smoke.BRL.MIL>, by gwyn@smoke.BRL.MIL (Doug Gwyn): > [...] There are many instances in C coding when the natural > expression of a simple statement (not talking about entire loops, etc., > but rather things like expression statements) simply does not fit on a > single line within such a length limit. [...] But, this is clearly (and observably) a _LESS_ common situation than when the statement _does_ fit on a single line. Even when indenting is used heavily for flow control display, the overwhelming majority of the code consists of one statement per line. In the comparatively rare instance when a statement must span several lines, an explicit continuation character could be used (NO - I don't mean Fortran and always column 6, etc.). That way, the majority of statements wouldn't need the redundant semicolon (and the concurrent threat of error if you accidentally omit it).
bobmon@iuvax.cs.indiana.edu (RAMontante) (04/28/89)
I said: - -You've just convinced me that you don't know what you're talking about. With a better-rested head on my shoulders, I wish to apologize to Mr. Giles for this unwarranted insult. The arguments can stand or fall on their own merits, and needn't be buttressed by inconsequential personal jabs. Sincerely, R A Montante
mat@mole-end.UUCP (Mark A Terribile) (04/28/89)
> > Speaking of doubleprecision, the next topic of discussion is why C > > believes in whitespace. (Did I say we shouldn't'a started this?) > Yes. For example, why does C treat a carriage return as whitespace? > Nobody programs like that. Most people put _one_ statement per line, > so the use of _both_ semicolon and carriage return as statement terminators > seems redundant. Why does C choose to ignore the "wrong" one? There's a 4-letter word that's considered very impolite on netnews. It's D U M B . Well, that's what this is. (And I'm violating nettiquitte by an ad-hominem attack, I know.) (Or else D U M B is what I am for taking this claptrap seriously.) Whitespace is not a statement terminator; whitespace seperates adjacent tokens that might otherwise be seen as one token. Why was it done this way? At the risk of getting the story all wrong, it's because the experience of some very bright, very experienced people suggested that this way works better than any other that's been tried. I suppose that you'd rather write continuation line markers than semicolons? FORTRAN uses the end of the line; PL/I (which came later) uses semicolons. Besides, just what constitutes a statement? { statement-list } is a statement. Where do you put the newlines? (Don't bother answering, please!) > And, of course, THANKS. Now I can claim to have been actually flamed by > Dennis Ritchie HIMSELF on _two_ occasions! 8-) He's flamed far better than you, kiddo! -- (This man's opinions are his own.) From mole-end Mark Terribile
nevin1@ihlpb.ATT.COM (Liber) (04/29/89)
In article <12716@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >Most people put _one_ statement per line, No. Most people put AT MOST one statement per line. Many times, due to indentation, long variable names, etc., it is not possible to put a whole statement on just one line. Heck, even your beloved FORTRAN allows you to split lines (a minus sugn in the sixth column, I believe). >so the use of _both_ semicolon and carriage return as statement terminators >seems redundant. That's why carriage returns AREN'T statement terminators. >Why does C choose to ignore the "wrong" one? Using carriage returns as statement terminators leads to much trickier rules for line continuation. For example: is x = 1 -y one statement or two? It's not obvious which should be better (please, let's NOT debate it). [insert Sousa march here, and roll the credits :-)] -- _ __ NEVIN ":-)" LIBER nevin1@ihlpb.ATT.COM (312) 979-4751 IH 4F-410 ' ) ) "I will not be pushed, filed, stamped, indexed, / / _ , __o ____ briefed, debriefed or numbered! My life is my own!" / (_</_\/ <__/ / <_ As far as I know, these are NOT the opinions of AT&T.
bb16@prism.gatech.EDU (Scott Bostater) (01/10/90)
I'm looking for a FORTRAN to C conversion program. PD/Shareware/$$$ anything
that will work. I'm trying to convert 50K lines of Vax Fortran (with
extensions) to unix. I'm willing to bite the bullet on Vax extensions, but
would be interested in having most/some of the code translation automated.
The host platform is not important, I can move the code to pretty much any
machine/OS.
Please e-mail and I'll post a summary if there's enough interest.
--
Scott Bostater GTRI/RAIL/RAD (Ga. Tech)
"My soul finds rest in God alone; my salvation comes from Him" -Ps 62.1
uucp: ...!{allegra,amd,hplabs,ut-ngp}!gatech!prism!bb16
Internet: bb16@prism.gatech.eduesok@ohs.UUCP (Eric Sokolowsky) (07/26/90)
I am looking for a Fortran to C converter program. I need it to run on
a Hewlett-Packard 9000 series (?) model 340 (?) UNIX machine. Any help
would be MUCH appreciated. Please E-mail Responses, since I do not
subscribe to either of these newsgroups. Thanks in advance.
My address is: iconsys!ohs!esok
--
*******Eric Sokolowsky (iconsys!ohs!esok)
_/\__/\__/\__/\__/\__/\__/\__/\__/\__/\__/\__/\__/\__/\__/\__/\_
| For Lack Of A Better Signature............................. |
\__/\__/\__/\__/\__/\__/\__/\__/\__/\__/\__/\__/\__/\__/\__/\__/raymond@math.berkeley.edu (Raymond Chen) (03/25/91)
Fortran to C conversion:
Karen Anderson (anderson@eecs.cs.pdx.edu) did a lot of work in collecting
this information. Any additions or corrections to this document
would be greatly appreciated; please send them to raymond@math.berkeley.edu.
Standard disclaimers apply. Opinions are those of the original authors.
Typing and editing errors are mine.
===============================================================================
f2c
-------------------------------------------------------------------------------
Joshua Simons (simons@think.com) and Mark.Maimone@a.gp.cs.cmu.edu
posted the press release:
Source for f2c, a Fortran 77 to C translator jointly developed
by folks from Bell Labs, Bellcore, and Carnegie Mellon, is now
freely available.
F2c was derived from the original UNIX operating system's f77(1),
and the generated C follows f77's calling conventions; on some
machines, the resulting object files are interchangeable with
(and behave indistinguishably from) objects compiled by f77.
The main "advantage" of f2c is that it converts ANSI standard
Fortran 77 into C without manual intervention, at least when
invoked by a suitable script or makefile (that may need to exercise
an f2c option to ensure that COMMON blocks are defined just once).
The main "problems" are that f2c does no code restructuring
(e.g., gotos are preserved) and that Fortran I/O gets converted
into a bunch of calls; thus the translated C code doesn't look
too pretty, and in general one would need to maintain the Fortran
rather than its translation into C. [Indeed, maintainable C code
was specifically *not* an objective of the f2c project. The
intent is that you maintain the Fortran. The f2c tech report
comments that producing maintainable C automatically seems to
require some amount of manual intervention even using commercial
($$$) translator programs. -- Henry Spencer]
There is a plethora of options, many of which exist to support
different compilation environments for the translated C (e.g.,
ANSI C or C++ compatability, different type sizes, separate files
for COMMON blocks to appease "smart" linkers). So far f2c (and
f2c-generated source) has compiled successfully on many machines:
Sun, Vax, IBMRT, Apollo, SGI, MIPS, and Cray to name a few.
F2c has been under test by the net community for over six months
[as of 27 Apr 90], and has been verified on the NBS tests,
several large math libraries, floating point tests, even code for
laying cable on the ocean floor!
To find about f2c, send the following E-mail message to netlib
(netlib@research.att.com or research!netlib):
echo send index from f2c | mail netlib@research.att.com
Your message will be answered automatically (by a program --
see CACM vol. 30 #5 (May, 1987), pp. 403-407). You will receive
a reply explaining how to automatically acquire f2c source
(about 600K), f2c library source (130K), and supporting info
(man page, etc).
To get it using anonymous FTP, ftp research.att.com and cd to
directory dist/f2c. All files are stored in compressed
format. [Make sure to pick up the runtime libraries libf77
and/or libi77.]
****************************** DISCLAIMER ******************************
Careful! Anything free comes with no guarantee.
************************************************************************
-------------------------------------------------------------------------------
Mike Black (black@seismo.CSS.GOV) reports:
I tried using f2c from the at&t distribution. If your desperate, it
might be worth it. But the code is a nightmare to read. I've done hand
conversions before with much better results than f2c. [See the comment
by Henry Spencer for an explanation.]
-------------------------------------------------------------------------------
Larry Jones (sdrc!scjones%thor@uunet.UU.NET) writes:
I haven't used f2c myself, but it's gotten rave reviews from others
here who have used it.
-------------------------------------------------------------------------------
Rick Stevens (zardoz!tmiuv0!rick@decwrl.dec.com) says:
There's a huge bugger from ATT Bellcore called F2C. It's written in C
(natch) and is FTPable. It's big, and you'll have to build it for your
system, however it does work and works quite well.
-------------------------------------------------------------------------------
And from Hans Georg v. Zezschwitz (zeschwitz@imdm.uke.uni-hamburg.dbp.de):
I'm am currently trying to work with the standart f2c (from netlib@att...)
Till now I made only one attempt with a Fortran program from a microVax.
It was for parametrization of eeg-segments. Apart from screen-specific
adaptions I had to edit it worked directly on a Unix (Xenix) system
(under C - of course).
For I rather don't know much about Unix nor Fortran I otherwise anyway
would not have coped with occuring problems.
===============================================================================
Cobalt Blue
-------------------------------------------------------------------------------
ubbpc!wgh@PRC.Unisys.COM (William G. Hutchison) writes:
We have had a client port an X-window application successfully from
FORTRAN to C using the Cobalt Blue converter.
-------------------------------------------------------------------------------
Tim.Ouellette@FtCollins.ncr.com says:
Of the Fortran-to-C convertors I've seen. They've dealt with
the simple commands okay. The main downfall I've seen is that they
don't have any way of dealing with the FORTRAN 'EQUIVALENCE'
statement. I've listed one's I seen advertised below. Hope it helps.
FOR_C by Cobalt Blue
2940 Union Ave, Ste C
San Jose CA 95124
(408)723-0474
-------------------------------------------------------------------------------
Ralph Carpenter (ralphc@tekcae.CAX.TEK.COM) adds,
A demo disk is available for around $10. It converts subroutines
that are less than 1K in size.
The address and phone of a mail order source:
The Programmer's Connection
7249 Whipple Ave NW
North Canton, OH 44720-7137
(800) 336-1166
Price as of 1 Jan 1990 (including surface UPS shipping):
$442 with binary runtime, ($575 list).
$673 with runtime sources, ($875 list).
-------------------------------------------------------------------------------
Steve Fullerton (scf%statware.uucp@cs.orst.edu) notes:
Cobalt Blue, a company out of San Jose has 2 FORTRAN-to-C translator
products, FOR_C and FOR_C++. I have a copy of FOR_C and have seen demos
of FOR_C++. If you need to deal with complex variables, then take a
look at FOR_C++. The translation results in very readable code. FOR_C
also handles complex but the resulting code might be best described as
spaghetti, although it does a very nice job on other standard and
non-standard FORTRAN.
Their address and phone: Cobalt Blue
1683 Milroy, Suite 101
San Jose, CA 95124
408/723-0474
===============================================================================
Promula.Fortran
-------------------------------------------------------------------------------
orszak@cfa243.harvard.edu (Jeff Orszak) sent a post which appeared on
comp.lang.fortran written by tohanson@gonzo.lerc.nasa.gov (Jeff Hanson).
In Digital Review (June 18, 1990) there is a review of Promula.Fortran, a
Fortran to C source code translator on pages 29 - 31.
The Test Brief follows
Vendor: Promula Development Corp.
3620 N. High St.
Suite 301
Columbus, OH 43214
(614) 263-5454
Test configuration: Promula.Fortran version 2.01 installed on a VAXstation
II/GPX running VMS 5.2
Price as Tested: $995.
Pros: Includes many command line options
Can produce various "flavors" of C code
Supports all VAX Fortran data types except REAL*16
Successfully translated STRUCTURE and RECORD decalarations including
UNION and MAP statements
Cons: I/O subroutine library did not work properly with ANALYSIS and PHILCO
(2 of the DR Labs test programs)
Defaulted to pointer notation for representing arrays, which is unclear
and less efficient in VAX C
Required dialect and error message files to be copied to current
working directory for translation
Used double quotes for include file specifications but incorrectly
defines VAXC$INCLUDE rather than C$INCLUDE
Non VMS-style command line options
The final 2 paragraphs of the review are:
With the exception of some undesirable default options, less-than-ideal
handling of some I/O statements and unsatisfactory handling of the DATA
statement, Promula.Fortran is a very useful utility for users who must
translate large amounts of Fortran to C. It translates quickly and generates
well-written and - with some expections - immediately executable C code.
Promula.Fortran has options that give users control over the C code produced.
Promula.Fortran's C code is very amenable to C programmers; it uses C
language conventions and, to put it simply, "feels" like C.
I have not seen this product and this posting should not be seen as an
endorsement for Promula. It should be seen as a high endorsement for DR Labs.
===============================================================================
for2c
-------------------------------------------------------------------------------
daveo@mipon3.intel.com (David O'Brien) writes:
I worked with a program about 18 months ago called for2c or something
like that. It was DOS based. I delt with the designer himself and
had good success. If you would like, I can go dig the name/company up
for you. I know right were they are at home. Let me know.
===============================================================================
Green Hills Software, Inc.
-------------------------------------------------------------------------------
unisoft!peritek!dig (Dave Gotwisner) found this advertisement:
Green Hills Software, Inc.
425 East Colorado Street, Suite 710
Glendale, CA 91205
(818) 246-5555
FAX: 818-246-7037
I don't know how good it is, but we use one of their
other products (a 68K cross compiler running under VMS), and it is quite
good. Binary copies can be gotten from:
OASYS, Inc.
230 Second Ave.
Waltham, MA 02154
617-890-7889
From the data sheet:
Language
* ANSI Fortran-77 (Full language)
* DoD Mil-STD 1753
* VAX/VMS Extensions
* NAMELIST
* Full Syntax OPEN
* STRUCTURES
* %VAL, %REF, %LOC
* !comments
* ENCODE/DECODE
* INTEGER *1, *2
* Octal/Hex constants
* etc.
Optimizations
* Register allocation
* Strength reduction
* Loop Invariant elimination
* Common subexpressions
* Value propagation
* Tail recursion
* Loop rotation
* Static address elimination
Hosts
VAX/UNIX Sun-2 386 UNIX/DOS
VAX/VMS Sun-3
(others by arrangement)
For further information, please contact either OASYS or Green Hills.
===============================================================================
A masters thesis
-------------------------------------------------------------------------------
Roger Christman (dvl@psuvm.bitnet) is working on a Fortran-to-C
translator for his Masters thesis at Penn State U. Here's what
he says:
It is designed to accept any Fortran 66
program and translate it into an equivalent C source. Program flow
structure is analyzed so that even the messiest GOTO arrangements
should find themselves better approximating such things as loops
and switches. ...
The upshot of all this is that the resulting program will be more
intuitively structured, as well as more efficient than the original.
As an example of current benchmarks, using the F77 and CC compilers
on a Sun Workstation Unix machine, my program is doing quite well.
The time required to translate into C and compile there is less than
the original Fortran compilation time. Also, the object code in C
executes faster than the original Fortran.
If you would like to find out more later on, when I approach the end
of the project, please send me mail at this address. I must warn you
that this project is for academic reasons alone, and is not designed
with production-scale error-checking. If your program will not compile
in Fortran 66, don't expect this translator to give you very meaningful
results.
===============================================================================
General comments
-------------------------------------------------------------------------------
On the subject of source code conversions in general
ittc!fbresz@uunet.UU.NET gets the last word:
Hi,
I have seen this question asked a few time and I finally decided to
send an email to someone so ..
I used to work for a company involved in such business. We would
for a price take your working FORTRAN code and convert it to C. Now this
was not cheap nor was it easy. I spent 1 entire year of my life on a
project which bore little fruit. So I am of the opinion that it might just
be easier to recode. Also you might want to think about waht you mean by
translation, we of course had the bizarre definition, runs identically to
FORTRAN. This leads into reproducing all the bizarre behaviours of FORTRAN
and if you think thats hard try doing PL/I => C we also did that or how
about PL/I => Ada. For these reasons (i.e. my brain is fried) I no longer
do much programming. I run a medium sized network for Westinghouse in
which the biggest programming task is getting sendmail.cf files workking
correctly . But seriously if you would care to have even more information
about translation, the company I used to work for has long since evaporated.
I can then tell you anything you want to know without problems of revealing
corporate secrets.
Frank P. Bresz }*{
ITTC Network Administrator
===============================================================================