code speed moving from fortran 77 compiler to f2003 compiler
in [Fortran]
|
From: steve on 25 Jun 2010 23:53 On Jun 25, 6:03 pm, Lynn McGuire <l...(a)winsim.com> wrote: > >> My long term goal is to convert our F77 code to C++ using FOR_C. > >> We may be trying this later this year when all of our Hollerith > >> code is gone. > > A couple of points to quote in that regard: > > > i) Cobalt-Blue's FOR_C is an F77 to C (NOT C++) converter. > > Yes. But converting C code to C++ code is fairly easy. I've done > it several times now. However, converting char * strings to STL > strings is non-trivial but that can be done later. > > > ii) FOR_C may choke on many of the non-standard F77 extensions used in > > your code. > > Nope. FOR_C understands the vax structure, union, map and record > keywords. That is the only extension that we are currently using. > > Thanks, > Lynn Elsewhere you discuss a custom memory allocator where you need to use EQUIVALENCE in a nonstandard way. I suspect you have many more extensions than you can easily enumerate here. Given that you appear to have problems porting Fortran from Watcom to another compiler, I further suspect you'll have problems with a fortran to c++ conversion. -- steve
From: mecej4 on 26 Jun 2010 08:22 On 6/25/2010 8:16 PM, e p chandler wrote: > > "mecej4" <mecej4.nyetspam(a)operamail.com> wrote in message > news:i03iq8$har$1(a)news.eternal-september.org... >> Lynn McGuire wrote: >> >> <...> >>> My long term goal is to convert our F77 code to C++ using FOR_C. >>> We may be trying this later this year when all of our Hollerith >>> code is gone. >> A couple of points to quote in that regard: >> >> i) Cobalt-Blue's FOR_C is an F77 to C (NOT C++) converter. >> >> ii) FOR_C may choke on many of the non-standard F77 extensions used in >> your code. >> >> -- mecej4 > > What about the quality of the converted code? Can you read it? Can you > maintain it? Or is it guacamole? > > It is many years since I last tried FOR-C. The impression that I obtained was that the C produced was more readable and maintainable than the output of AT&T f2c; the latter was more fit to be used as a pre-processor prior to calling a C compiler. -- mecej4
From: dpb on 26 Jun 2010 09:05 Lynn McGuire wrote: >>> had one of my guys add an isothermal flash cache to our general >>> flash. ... >> >> In a quick moment before heading to fields... >> >> I have no clue what you just said??? > .... > So anyway, we save the results of the calculations now. If the > flowsheet wants to make the same exact calculation again, we already > have it saved. Apparently saves a lot of time ! .... Too much wheat chaff yesterday, I suppose... :) It dawned on me during the day what you meant; I initially read the "flash" as memory, not in the thermodynamic sense and that sent me off on a tangent... On a side note, harvest '10 is over for us...finished not terribly late last night; now let it rain... :) Very sad note; a couple of outstanding young men (college kids working summer) were killed in an grain elevator mishap day before yesterday when two of the silos failed and buried them while unloading a semi at an outside dump pit in Russell, KS. It was a structural failure, not a grain dust explosion. Russell is in north central KS, roughly 200 miles NE from us. --
From: Lynn McGuire on 26 Jun 2010 11:32 > Elsewhere you discuss a custom memory allocator where > you need to use EQUIVALENCE in a nonstandard way. I > suspect you have many more extensions than you can > easily enumerate here. I am thinking about moving our variant data type from our structure to several equivalanced arrays. But that was so I could try the ftn95 compiler. I just found out that the absoft compiler supports structure. > Given that you appear to have problems porting Fortran > from Watcom to another compiler, I further suspect you'll > have problems with a fortran to c++ conversion. Me too. We use the /save feature of the watcom compiler, I keep on forgetting that is an extension. It does save and zero init automatically also. I need to get us off this feature, possibly by initializing all of our local variables. Thanks, Lynn
From: Lynn McGuire on 26 Jun 2010 11:44
> It is many years since I last tried FOR-C. The impression that I obtained was that the C produced was more readable and > maintainable than the output of AT&T f2c; the latter was more fit to be used as a pre-processor prior to calling a C compiler. Thanks for the analysis of for_c. I had a friend take a 100,000 line f77 app to c with it several years ago. He was porting to a Fujitsu unix machine that only had a c compiler. He thought for_c was OK also, not great. But they stayed with fortran for the main lanaguage of their app and just reran for_c when necessary. Thanks, Lynn |