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?
steve@hubcap.clemson.edu ("Steve" Stevenson) (08/25/89)
I know it comes up all the time here ---- We need a converter from UNIX f77 to C. Please reply direct to either * Steve Stevenson --- steve@hubcap.clemson.edu * R. M. Geist --- geist@hubcap.clemson.edu Thanks -- Steve (really "D. E.") Stevenson steve@hubcap.clemson.edu Department of Computer Science, (803)656-5880.mabell Clemson University, Clemson, SC 29634-1906
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............................. |
\__/\__/\__/\__/\__/\__/\__/\__/\__/\__/\__/\__/\__/\__/\__/\__/