leipold@eplrx7.uucp (Walt Leipold) (05/30/91)
I've used f2c, and it works fine -- at least, the generated C code compiles and runs on a Un*x system. The C code also compiles under Think C on the Macintosh, but it won't link without f2c's 'standard' libraries, libF77 and libI77. Can anyone out there who has ported these libraries to the Mac give me some hints? *Has* anyone used f2c to generate code for the Mac? I don't want to run f2c on a Mac; I just want to run the C code it generates. As usual, email is fine... Thanks! -- -------------------------------------------------------------------------- "What's the matter?" Walt Leipold "Eddies in the space-time continuum." (leipold%eplrx7@uunet.uu.net) "Well, tell him to get out!" (leipolw%esvax@dupont.com) -- The UUCP Mailer
dent@DIALix.oz.au (Andrew Dent) (06/01/91)
In <1991May30.040829.8696@eplrx7.uucp> leipold@eplrx7.uucp (Walt Leipold) writes: >I've used f2c, and it works fine -- at least, the generated C code compiles >and runs on a Un*x system. The C code also compiles under Think C on the >Macintosh, but it won't link without f2c's 'standard' libraries, libF77 and >libI77. Can anyone out there who has ported these libraries to the Mac >give me some hints? *Has* anyone used f2c to generate code for the Mac? I >don't want to run f2c on a Mac; I just want to run the C code it generates. I'd be very interested to hear if f2c generates successful code for the Mac as I've spent most of the past 3 months writing a converter from FORTRAN to THINK Pascal. The biggest problem I encountered is the way the Mac stores integers, which causes major problems with arrays of different cell sizes being EQUIVALENCED. eg: INTEGER*2 little(2) INTEGER*4 big EQUIVALENCE (little,big) little(1) = 10 little(2) = 99 on VMS & MS-DOS, big would now have the value 6488074 on Mac: 655459 because the bytes are stored in the opposite order to all FORTRAN implementations. I think that MacFORTRAN has the same problem (without trying to fix it) which means people porting code to the Mac will have a nasty time of it (the stuff I'm translating has algorithms that use overlaid 4 & 2 byte integers all the time, AND the actual binary representations are important:-( BTW - IS there an equivalent of f2c around, for Pascal? Andy Dent A.D. Software phone 09 249 2719 Mac & VAX programmer 94 Bermuda Dve, Ballajura dent@DIALix.oz Western Australia 6066 dent@DIALix.oz.au (international)
orville@weyrich.UUCP (Orville R. Weyrich) (06/02/91)
In article <1017@DIALix.oz.au> dent@DIALix.oz.au (Andrew Dent) writes: > >I'd be very interested to hear if f2c generates successful code for the >Mac as I've spent most of the past 3 months writing a converter from FORTRAN to >THINK Pascal. The biggest problem I encountered is the way the Mac stores >integers, which causes major problems with arrays of different cell sizes >being EQUIVALENCED. > >eg: INTEGER*2 little(2) > INTEGER*4 big > EQUIVALENCE (little,big) > little(1) = 10 > little(2) = 99 > >dent@DIALix.oz.au (international) Of course you are having trouble translating. Your source code is NOT FORTRAN, at least in the sense of conforming to the FORTRAN-66 and FORTRAN-77 standards. [I don't have my copy of the standard handy, so I can't quote verbatim, but the general idea is that when equivalencing dissimilar types, it can be done only to save storage by re-using the same statically allocated region in non-interacting parts of the program. Creative use of EQUIVALENCE to do bit-twiddling is not allowed by the standard. In your example, when array "little" becomes defined, array "big" becomes undefined, and vice-versa]. This is not an issue pertaining to translating FORTRAN to Pascal. This is an issue pertainig to porting non-standard FORTRAN code from one hardware platform to another. That is, you should have no problem translating a program that works in Mac FORTRAN to Mac Pascal. The problem you are experiencing is EXACTLY the reason why the FORTRAN standard does not allow using EQUIVALENCE in the way your source code does. This leads to the $500,000 question: do algorithms exist which can do something intelligent with such uses of EQUIVALENCE? YES, I WOULD BE VERY INTERESTED IN THE ANSWER TO THE ABOVE QUESTION. Failing to get an acceptable answer to that question, my best advice is to do one of the following: 1) Flag that portion of the translation as needing manual attention. or 2) Modify the original source code to not mis-use EQUIVALENCE before attempting the translation. Neither of these are particularly desirable :-(. By the way, you are not alone. There is commercial software that is known for its portability (the IMSL mathematical library) that [at least used to] play such standard-breaking tricks with equivalence in order to implement extended precision addition and multiplication (VXPADD, VXPMUL as I recall). They hid the standard violation inside small subroutines, and had separate versions of the subroutines for different hardware platforms. -------------------------------------- ****************************** Orville R. Weyrich, Jr., Ph.D. Certified Systems Professional Internet: orville%weyrich@uunet.uu.net Weyrich Computer Consulting Voice: (602) 391-0821 POB 5782, Scottsdale, AZ 85261 Fax: (602) 391-0023 (Yes! I'm available) -------------------------------------- ******************************
silvert@cs.dal.ca (Bill Silvert) (06/03/91)
In article <1991Jun1.171914.802@weyrich.UUCP> orville@weyrich.UUCP (Orville R. Weyrich) writes: >>The biggest problem I encountered is the way the Mac stores >>integers, which causes major problems with arrays of different cell sizes >>being EQUIVALENCED. >> >>eg: INTEGER*2 little(2) >> INTEGER*4 big >> EQUIVALENCE (little,big) >> little(1) = 10 >> little(2) = 99 The usage INTEGER*n is non-standard. As Orville goes on to say, asking a translator to support non-standard usage is a bit much. -- William Silvert, Habitat Ecology Division, Bedford Inst. of Oceanography P. O. Box 1006, Dartmouth, Nova Scotia, CANADA B2Y 4A2. Tel. (902)426-1577 UUCP=..!{uunet|watmath}!dalcs!biome!silvert BITNET=silvert%biome%dalcs@dalac InterNet=silvert%biome@cs.dal.ca
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (06/03/91)
In article <1017@DIALix.oz.au>, dent@DIALix.oz.au (Andrew Dent) writes: > In <1991May30.040829.8696@eplrx7.uucp> leipold@eplrx7.uucp (Walt Leipold) writes: > The biggest problem I encountered is the way the Mac stores > integers, which causes major problems with arrays of different cell sizes > being EQUIVALENCED. > eg: INTEGER*2 little(2) > INTEGER*4 big > EQUIVALENCE (little,big) > little(1) = 10 > little(2) = 99 > on VMS & MS-DOS, big would now have the value 6488074 > on Mac: 655459 because the bytes are stored in the opposite order to all > FORTRAN implementations. 1. INTEGER*2 and INTEGER*4 are not standard Fortran. They have equivalents (INTEGER(KIND=...)) in Fortran 90, but not in Fortran 66 nor in Fortran 77. The Fortran 77 standard makes it very clear indeed that there is only *one* standard size of integer, and that - LOGICAL, INTEGER, and REAL all occupy exactly one "storage unit" - COMPLEX and DOUBLE PRECISION both occupy exactly two "storage units". Yes, this does mean that any Fortran compiler which has a mode in which REAL is 4 bytes and INTEGER is 2 bytes does not _in_that_mode_ conform to the standard. 2. EQUIVALENCE in Fortran 66 and Fortran 77 is just like tagless variant records in Pascal. It is a device for re-using storage for any _one_ of several different things, _not_ a device for accessing storage several ways at once. The standard makes it clear that when a value is assigned to an equivalenced variable, that variable becomes defined, and the variables associated with it become UNdefined. So even if INTEGER*2 and INTEGER*4 were standard Fortran, after the assignment little(1) = 10, the value of 'big' is undefined and no conforming program could depend on it. 3. The claim that "all Fortran implementations" use the (extremely sensible) "little-endian" byte order that the VAX and the 80*86 use is grossly at variance with the facts. (Indeed, the Fortran 77 standard very carefully omits EQUIVALENCEing character and non- character data precisely in order to conceal whatever relationship there may be between storage units and character storage units from conforming programs.) IBM 370s use the same byte order as M680x0s. -- Should you ever intend to dull the wits of a young man and to incapacitate his brains for any kind of thought whatever, then you cannot do better than give him Hegel to read. -- Schopenhauer.
dent@DIALix.oz.au (Andrew Dent) (06/03/91)
In <1991Jun2.182915.486@cs.dal.ca> silvert@cs.dal.ca (Bill Silvert) writes: >The usage INTEGER*n is non-standard. As Orville goes on to say, asking >a translator to support non-standard usage is a bit much. I DISAGREE - the "standard" that must be supported by a useable tool is the standard of the marketplace, not the "official" standards that everyone ignores. I don't know any FORTRAN's apart from Mac, VAX/VMS & MS-DOS but I'd bet that *MOST* of them support INTEGER*n (of some form). Heck, half the compilers I see advertised now make a point of supporting the VAX/VMS extensions! By the way, in an earlier posting I suggested that ALL FORTRANS have the reverse byte-order that causes so much trouble translating or porting to the Mac, this is of course WRONG and is a feature of the host CPU. What can I say - it was late, I was tired, depressed, the code wasn't working, it was raining ... From what I've read lately, there's going to be a mass revolt against the new "official" standards anyway :-) >-- >William Silvert, Habitat Ecology Division, Bedford Inst. of Oceanography >P. O. Box 1006, Dartmouth, Nova Scotia, CANADA B2Y 4A2. Tel. (902)426-1577 >UUCP=..!{uunet|watmath}!dalcs!biome!silvert >BITNET=silvert%biome%dalcs@dalac InterNet=silvert%biome@cs.dal.ca Andy Dent A.D. Software phone 09 249 2719 Mac & VAX programmer 94 Bermuda Dve, Ballajura dent@DIALix.oz Western Australia 6066 dent@DIALix.oz.au (international)
jlg@cochiti.lanl.gov (Jim Giles) (06/03/91)
In article <6081@goanna.cs.rmit.oz.au>, ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: |> [...] |> 3. The claim that "all Fortran implementations" use the (extremely |> sensible) "little-endian" byte order that the VAX and the 80*86 use |> is grossly at variance with the facts. [...] |> [...] IBM 370s use the same byte order as M680x0s. True. And Cray, CDC and other word addressed machines tend to be "big-endian" (for _all_ languages, not just Fortran). J. Giles
vsnyder@jato.jpl.nasa.gov (Van Snyder) (06/04/91)
In article <1017@DIALix.oz.au> dent@DIALix.oz.au (Andrew Dent) writes: >In <1991May30.040829.8696@eplrx7.uucp> leipold@eplrx7.uucp (Walt Leipold) writes: > >>I've used f2c, and it works fine -- at least, the generated C code compiles >>and runs on a Un*x system. The C code also compiles under Think C on the >>Macintosh, but it won't link without f2c's 'standard' libraries, libF77 and >>libI77. Can anyone out there who has ported these libraries to the Mac >>give me some hints? *Has* anyone used f2c to generate code for the Mac? I >>don't want to run f2c on a Mac; I just want to run the C code it generates. > >I'd be very interested to hear if f2c generates successful code for the >Mac as I've spent most of the past 3 months writing a converter from FORTRAN to >THINK Pascal. The biggest problem I encountered is the way the Mac stores >integers, which causes major problems with arrays of different cell sizes >being EQUIVALENCED. > >eg: INTEGER*2 little(2) > INTEGER*4 big > EQUIVALENCE (little,big) > little(1) = 10 > little(2) = 99 > >on VMS & MS-DOS, big would now have the value 6488074 >on Mac: 655459 because the bytes are stored in the opposite order to all >FORTRAN implementations. > >I think that MacFORTRAN has the same problem (without trying to fix it) >which means people porting code to the Mac will have a nasty time of it >(the stuff I'm translating has algorithms that use overlaid 4 & 2 byte >integers all the time, AND the actual binary representations are important:-( > For doing such a thing, you deserve what happens to you. -- vsnyder@jato.Jpl.Nasa.Gov ames!elroy!jato!vsnyder vsnyder@jato.uucp
mroussel@alchemy.chem.utoronto.ca (Marc Roussel) (06/06/91)
In article <1991Jun1.171914.802@weyrich.UUCP> orville@weyrich.UUCP (Orville R. Weyrich) writes: [on using EQUIVALENCE with variables of differing types] >This leads to the $500,000 question: do algorithms exist which can do something >intelligent with such uses of EQUIVALENCE? > >YES, I WOULD BE VERY INTERESTED IN THE ANSWER TO THE ABOVE QUESTION. I can see one possible legitimate use of EQUIVALENCE with different data types: to decide on the endianism of your machine (and similarly to decide other quirks of the number system of the computer). You can load up some variables with known values, equivalence them to appropriate-sized integers and then use these integers to diagnose the endianism (round-off, etc.). Such diagnostic toolkits are probably the only legitimate use of equivalence across data types though (other than saving space). Anyone know any others? Marc R. Roussel mroussel@alchemy.chem.utoronto.ca
orville@weyrich.UUCP (Orville R. Weyrich) (06/07/91)
In article <1991Jun5.220805.4653@alchemy.chem.utoronto.ca> mroussel@alchemy.chem.utoronto.ca (Marc Roussel) writes: >In article <1991Jun1.171914.802@weyrich.UUCP> orville@weyrich.UUCP >(Orville R. Weyrich) writes: >[on using EQUIVALENCE with variables of differing types] >>This leads to the $500,000 question: do algorithms exist which can do something >>intelligent with such uses of EQUIVALENCE? >> >>YES, I WOULD BE VERY INTERESTED IN THE ANSWER TO THE ABOVE QUESTION. > >I can see one possible legitimate use of EQUIVALENCE with different data >types: to decide on the endianism of your machine (and similarly to decide >other quirks of the number system of the computer). You can load up some >variables with known values, equivalence them to appropriate-sized integers >and then use these integers to diagnose the endianism (round-off, etc.). Such >diagnostic toolkits are probably the only legitimate use of equivalence >across data types though (other than saving space). Anyone know any others? > Of course, you beg the question. Why do you need to know the endianism if you are writing standard FORTRAN? One of the design goals of standard FORTRAN is to describe how to write programs that are hardware-independent. Of course, practice is at odds with theory. In the real world, programmers need to do bit-twiddling (or at least they feel a need :-). Bit-twiddling is not supported by standard FORTRAN (66 & 77). To do it you need to resort to non-standard, machine-specific, non-portable games with EQUIVALENCE (or other mechanisms for aliasing memory). Support for bit-twiddling has been in and out of FORTRAN-9x several times. I haven't looked to see what its status is now. -------------------------------------- ****************************** Orville R. Weyrich, Jr., Ph.D. Certified Systems Professional Internet: orville%weyrich@uunet.uu.net Weyrich Computer Consulting Voice: (602) 391-0821 POB 5782, Scottsdale, AZ 85261 Fax: (602) 391-0023 (Yes! I'm available) -------------------------------------- ******************************
mroussel@alchemy.chem.utoronto.ca (Marc Roussel) (06/07/91)
In article <1991Jun7.022834.898@weyrich.UUCP> orville@weyrich.UUCP (Orville R. Weyrich) writes: >In article <1991Jun5.220805.4653@alchemy.chem.utoronto.ca> >mroussel@alchemy.chem.utoronto.ca (Marc Roussel) writes: >>I can see one possible legitimate use of EQUIVALENCE with different data >>types: to decide on the endianism of your machine (and similarly to decide >>other quirks of the number system of the computer). > >Of course, you beg the question. Why do you need to know the endianism if you >are writing standard FORTRAN? I feel that my point has been missed. A standard-conforming Fortran program doesn't need to know about endianism, of course. On the other hand, I believed when I wrote the above that it was possible to write a standard-conforming program whose sole purpose was to determine endianism. To what devious uses you put this information is in some sense irrelevant (and more than likely non-standard). It has struck me since however that since the standard doesn't say what to do when one equivalences across data types, a particularly odd compiler could transform the "obvious" meaning of EQUIVALENCE into something else entirely (and still conform to the standard). (I believe that this situation is common when equivalencing any numerical type to CHARACTER because of the peculiar way in which character variables are stored in some systems.) I therefore retract my example. I don't think you can use equivalence portably to do anything other than save space. Marc R. Roussel mroussel@alchemy.chem.utoronto.ca
userAKDU@mts.ucs.UAlberta.CA (Al Dunbar) (06/08/91)
In article <1991Jun5.220805.4653@alchemy.chem.utoronto.ca>, mroussel@alchemy.chem.utoronto.ca (Marc Roussel) writes: >In article <1991Jun1.171914.802@weyrich.UUCP> orville@weyrich.UUCP >(Orville R. Weyrich) writes: >[on using EQUIVALENCE with variables of differing types] >>This leads to the $500,000 question: do algorithms exist which can do something >>intelligent with such uses of EQUIVALENCE? >> >>YES, I WOULD BE VERY INTERESTED IN THE ANSWER TO THE ABOVE QUESTION. > >I can see one possible legitimate use of EQUIVALENCE with different data >types: to decide on the endianism of your machine (and similarly to decide >other quirks of the number system of the computer). You can load up some >variables with known values, equivalence them to appropriate-sized integers >and then use these integers to diagnose the endianism (round-off, etc.). Such >diagnostic toolkits are probably the only legitimate use of equivalence >across data types though (other than saving space). Anyone know any others? > While you might be able to infer _some_ such information from _some_ machines, I doubt that any code you write would necessarily work on _all_ machines. A CDC Cyber xxx (I forget the number) has 60=bit integers, and does _not_ use two's complement arithmetic. I am not sure if its Fortran even supports shorter integers. EQUIVALENCE is an idea whose time has come and gone; or at least will be gone when Fortran 90 arrives with its TRANSFER function. -------------------+------------------------------------------- Al Dunbar | Edmonton, Alberta | Disclaimer: "not much better than CANADA | datclaimer" -------------------+-------------------------------------------
sampson@en.ecn.purdue.edu (John B Sampson) (06/11/91)
This is probably a popular question, but can someone tell me where a FORTRAN to C translator can be obtained for free? Unix, Mac, PC -- it doesn't matter. Thank you.