Looking for a real Fortran-66 compatible PC compiler (CP/M or DOS or Windows, doesn't matter)
Peter Dassow
I have to compile some very old Fortran-66 programs, but I do not have
an IBM host or a TOPS-10/VMS machine.
So I am looking for a real compatible compiler for these old sources,
Fortran-80 (CP/M) is one of the candidates, but there are problems with
the data types. Are there any other PC compatible Fortran-66 compilers
out there ?
Regards
Peter
Peter Flass
What do you want to do? Do you need to generate PC code, or just run on
a PC? There are PC-based emulators for IBM 360/370, VAX/VMS, and
TOPS-10. I know at least the IBM and DEC-10 emulators have FORTRAN
compilers, and I expect the VAX does also.
Peter Dassow
Peter,
I want to give them as .EXE / .COM away, so others without an emulator
can run these executables also.
Also, an emulator runs only perfect if you have the OS also installed,
VMS should be difficult (it must be licen$ed and the license is time
limited).
Regards
Peter
Dave Wade
"Peter Dassow" <z8...@arcor.de> wrote in message
news:4d175df4$0$6888$9b4e...@newsspool2.arcor-online.net...
The IBM really old IBM Operating systems are all copywrite free and you can
bundle up a Hercules that will run batch jobs, but I agree its over kill for
a few Fortran programs. The oldest compiler I know of that available for
download that runs on a PC is FTN-77 from here:-
http://www.silverfrost.com/53/ftn77/ftn77_dbos_history.aspx
but its really strict. I actually found that Open Watcom was a better bet
and has compiled most of the Fortran-66 without too many issues...
http://www.openwatcom.org/index.php/Main_Page
>
> Regards
> Peter
Dave
G4UGM
Peter Dassow
>
> I actually found that Open Watcom was a better
> bet and has compiled most of the Fortran-66 without too many issues...
>
> http://www.openwatcom.org/index.php/Main_Page
>
Watcom is really "fat" (~50MB) and the documentation is an endless PDF
file collection also. At the moment I am a bit concerned about such a
flood of files (compiler and docs).
Regards
Peter
Anne & Lynn Wheeler
"Dave Wade" <dave....@gmail.com> writes:
> The IBM really old IBM Operating systems are all copywrite free and
> you can bundle up a Hercules that will run batch jobs, but I agree its
> over kill for a few Fortran programs. The oldest compiler I know of
> that available for download that runs on a PC is FTN-77 from here:-
>
> http://www.silverfrost.com/53/ftn77/ftn77_dbos_history.aspx
>
> but its really strict. I actually found that Open Watcom was a better
> bet and has compiled most of the Fortran-66 without too many issues...
>
> http://www.openwatcom.org/index.php/Main_Page
aka ... the company was somewhat forced into unbundling announced
23jun69 ... and starting to charge for (application) software (among
other things); however the company did managed to make the case that
kernel software should still be free. misc. past posts mentioning
23jun69 unbundling & starting to charge for software
http://www.garlic.com/~lynn/submain.html#unbundle
the company then started the Future System effort, somewhat motivated by
clone controllers ... but it failed w/o even being announced. During
Future System ... much of the other activity was killed off ... allowing
the 370 hardware&software product pipelines to go dry ... then when
Future System was killed ... there was made rush to get stuff back into
the 370 hardware&software product pipeline. recent post mentioning
Future System
http://www.garlic.com/~lynn/2010q.html#33 IBM Future System
shutting down 370 "competition" for FS and then having a dry 370
(hardware) product pipeline (when FS was killed) is credited with clone
processors getting a foothold in the market.
Rushing to get stuff back into the 370 product pipeline ... and facing
the clone processors is possible motivation for the transition to
starting to (also) charge/license kernel software (as well as the
transition to object-code-only).
above Future System post also references these web page:
http://www.cs.clemson.edu/~mark/fs.html
and
http://www.jfsowa.com/computer/memo125.htm
as well as other past posts mentioning FS
http://www.garlic.com/~lynn/2010q.html#32
--
virtualization experience starting Jan1968, online at home since Mar1970
William Hamblen
How well goes gnu fortran77 work? You might be able to link with mingw32
to get a Microsoft Windows executible.
Bud
Tim Shoppa
Fortran 66 wasn't especially portable as usually written. You may have
to hack some of the source code up anyway. Why not just port it over
to 77? This is sort of stuff a Fortran programmer does over a lunch
break (e.g. not a big deal.)
Tim.
Peter Dassow
>
> Fortran 66 wasn't especially portable as usually written. You may have
> to hack some of the source code up anyway. Why not just port it over
> to 77? This is sort of stuff a Fortran programmer does over a lunch
> break (e.g. not a big deal.)
>
I have a collection of links already published at
http://www.z80.eu/for-compiler.html
but this was more CP/M centric ;-)
Regards
Peter
Tim Shoppa
> On 26.12.2010 22:48, Tim Shoppa wrote:
>
> > Fortran 66 wasn't especially portable as usually written. You may have
> > to hack some of the source code up anyway. Why not just port it over
> > to 77? This is sort of stuff a Fortran programmer does over a lunch
> > break (e.g. not a big deal.)
>
> Yes, meanwhile that's what I thought also.
> but this was more CP/M centric ;-)
IMHO:
Writing portable Fortran, is far easier than writing portable C.
That doesn't mean it's often done :-)
Most CP/M machines will be "too small" to run any but the most trivial
Fortran applications anyway. The threaded code PDP-11 compilers could
let you do interesting stuff in 64K (especially with overlays - wow,
overlays were so important in that memory model) but I never saw any
x80 compilers do anything nearly so usable.
Gnu fortran77, mentioned elsewhere in this thread, takes an
interesting tack: AFAIK it doesn't support anybody's F77 extensions.
Having grown up in a world defined by F77 extensions (especially VAX/
PDP-11 and DOD extensions) this was a cultural shock when I first saw
it, but I now appreciate Gnu fortran77's stoicness as a way of
enhancing portability.
Tim.
H Vlems
>
> - Tekst uit oorspronkelijk bericht weergeven -
A (free, hobbyist) VMS license obtained thru the Montagar program
lasts a year.
All you need is an Encompass associate membership, which is free as
well.
If you need media then ask on c.o.v. and a kind soul will help you.
Hans
Peter Flass
jmfbahciv
What CPU do you want this to run on? an old compiler would generate
286 machine instructions?
/BAH
Tim Shoppa
>
> > Fortran 66 wasn't especially portable as usually written. You may have
> > to hack some of the source code up anyway. Why not just port it over
> > to 77? This is sort of stuff a Fortran programmer does over a lunch
> > break (e.g. not a big deal.)
>
> Yes, meanwhile that's what I thought also.
> but this was more CP/M centric ;-)
Peter -
I originally the thread was about crufty old Fortran 66 code, but
now I see that you are bringing in
crufty old CP/M platform Fortran 77 compilers too :-).
Most generically you will be more productive dealing with crufty
code, than with crufty compilers.
IMHO the compilers you name were crufty even when they were brand
new :-). Nothing against the attempt to put Fortran on an 8-bit micro,
just that from my 2010 perspective they missed the mark every time.
Tim.
Dave Wade
"jmfbahciv" <See....@aol.com> wrote in message
news:PM0004986...@aca210e1.ipt.aol.com...
Both WATCOM and FTN77 generate 286 instructions but the code runs fine on
XP. I haven't tried on Windows/7 or 64 bit OS...
> /BAH
Charles Richmond
> On Dec 26, 4:53 pm, Peter Dassow<z8...@arcor.de> wrote:
>> On 26.12.2010 22:48, Tim Shoppa wrote:
>>
>>> Fortran 66 wasn't especially portable as usually written. You may have
>>> to hack some of the source code up anyway. Why not just port it over
>>> to 77? This is sort of stuff a Fortran programmer does over a lunch
>>> break (e.g. not a big deal.)
>>
>> Yes, meanwhile that's what I thought also.
>> I have a collection of links already published athttp://www.z80.eu/for-compiler.html
>> but this was more CP/M centric ;-)
>
> IMHO:
>
> Writing portable Fortran, is far easier than writing portable C.
>
I can only compare the porting of FORTRAN/66 or FORTRAN IV code to
porting programs written in C. In this comparison, ISTM that C is
much more portable. Perhaps FORTRAN 77 or later *is* more portable...
FORTRAN/66 and FORTRAN IV have *no* standard way to handle
character data in variables. This led to many non-portable
"tricks" to store character data.
--
+----------------------------------------+
| Charles and Francis Richmond |
| |
| plano dot net at aquaporin4 dot com |
+----------------------------------------+
Charles Richmond
Just out of curiosity, what are these FORTRAN/66 programs doing
that is important enough to warrant compiling on a PC???
Dave Wade
"Charles Richmond" <fri...@tx.rr.com> wrote in message
news:ifboth$d3$1...@news.eternal-september.org...
> On 12/26/10 7:08 PM, Tim Shoppa wrote:
>> On Dec 26, 4:53 pm, Peter Dassow<z8...@arcor.de> wrote:
>>> On 26.12.2010 22:48, Tim Shoppa wrote:
>>>
>>>> Fortran 66 wasn't especially portable as usually written. You may have
>>>> to hack some of the source code up anyway. Why not just port it over
>>>> to 77? This is sort of stuff a Fortran programmer does over a lunch
>>>> break (e.g. not a big deal.)
>>>
>>> Yes, meanwhile that's what I thought also.
>>> I have a collection of links already published
>>> athttp://www.z80.eu/for-compiler.html
>>> but this was more CP/M centric ;-)
>>
>> IMHO:
>>
>> Writing portable Fortran, is far easier than writing portable C.
>>
>
> I can only compare the porting of FORTRAN/66 or FORTRAN IV code to porting
> programs written in C. In this comparison, ISTM that C is much more
> portable. Perhaps FORTRAN 77 or later *is* more portable...
>
> FORTRAN/66 and FORTRAN IV have *no* standard way to handle character data
> in variables. This led to many non-portable "tricks" to store character
> data.
>
Fortran 77 has proper charter data. I spent about 10 years working on a file
transfer and job management package. The Salford Portable Communications
Package (SPCP) (any one still got a copy) was written in Fortran 77 because
at the time there were many machines without a "C" compiler. However the
code posed many challenges as there is no dynamic memory management in
Fortran 77. The solution was to use a couple of large arrays, one of
integers and one of characters. Among other things the integer array was
used to manage the entires in the character variables. The data in the
character variables was "structured" by use of contestants that delimited
the substrings. However this did require the use of the INCLUDE statement
which was an extension. I think we had a macro processor that could be used
if we met a compiler without INCLUDE...
>
> --
> +----------------------------------------+
> | Charles and Francis Richmond |
> | |
> | plano dot net at aquaporin4 dot com |
> +----------------------------------------+
Dave
G4UGM
jmfbahciv
> On 12/26/10 7:08 PM, Tim Shoppa wrote:
>> On Dec 26, 4:53 pm, Peter Dassow<z8...@arcor.de> wrote:
>>> On 26.12.2010 22:48, Tim Shoppa wrote:
>>>
>>>> Fortran 66 wasn't especially portable as usually written. You may have
>>>> to hack some of the source code up anyway. Why not just port it over
>>>> to 77? This is sort of stuff a Fortran programmer does over a lunch
>>>> break (e.g. not a big deal.)
>>>
>>> Yes, meanwhile that's what I thought also.
>>> I have a collection of links already published
athttp://www.z80.eu/for-compiler.html
>>> but this was more CP/M centric ;-)
>>
>> IMHO:
>>
>> Writing portable Fortran, is far easier than writing portable C.
>>
>
> I can only compare the porting of FORTRAN/66 or FORTRAN IV code to
> porting programs written in C. In this comparison, ISTM that C is
> much more portable. Perhaps FORTRAN 77 or later *is* more portable...
>
> FORTRAN/66 and FORTRAN IV have *no* standard way to handle
> character data in variables.
That's because characters weren't considered data back then.
> This led to many non-portable
> "tricks" to store character data.
>
>
Which should work, albeit slowerly.
/BAH
jmfbahciv
If the code had been running on a PDP-10, I'd have suggested using
the switch which causes the compiler to revert to an old standard.
However, I don't know if any of those PC compilers ever bothered
to support backwards compatible FORTRAN code.
/BAH
Dave Wade
"jmfbahciv" <See....@aol.com> wrote in message
news:PM0004987...@aca2ecfe.ipt.aol.com...
FTN77 isn't a "PC Compiler" its a Portable Fortran 77 Compiler that has been
ported to the PC environment. It started out life as a Fortran 77 compiler
for ICL 1900. ICL had refused to develop a Fortran 77 compiler for the 1900
Series and tried to get Universities to switch to 2900 series. When Salford
University "jumped ship" and switched from ICL1900 to PR1MOS, the PR1ME
machines they bought were benchmarked using the PR1ME Fortran 66 compiler as
the Fortran 77 compiler wasn't available when the machines were ordered.
When the PR1ME Fortran 77 compiler finally appeared its performance was dire
,and so FTN was ported to PR1MOS. Later as PCs became widely used within the
University an MS-DOS port was also produced, For many years the compilers
were formally ANSI certified but these days this doesn't happen for cost
reasons. Logically the compiler supports some extensions to allow Fortran 66
code to compile, refer to the user guide for details.
http://www.silverfrost.com/53/ftn77/ftn77_dbos_history.aspx
In a similar manner the Open WATCOM compilers are descended from earlier
mainframe tools, but in this case the lineage is not so clearly traceable.
Looking at the source code for V1.2 of OpenWatcom remnants of the IBM/360
code generation were still present but I never managed to get it to emit
"Mainframe" code. I note that it also supports Hollerith constants for
Fortran 66 compatability, but could not find the other options.
> /BAH
Dave
G4UGM
Peter Dassow
>> I have to compile some very old Fortran-66 programs, but I do not
>> have an IBM host or a TOPS-10/VMS machine.
>>
>
> important enough to warrant compiling on a PC???
>
only a sinus which calms down to zero ;-)
Regards
Peter
Peter Flass
remember it.
>
> /BAH
ArarghMai...@not.at.arargh.com
The IBM Fortran compiler for the PC (from 1982) has some support for
Fortran 66 compatability, but I don't know how much.
--
ArarghMail012 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html
To reply by email, remove the extra stuff from the reply address.
Charles Richmond
Yes, I used and liked FORTRAN 77. I just *never* had to port any
of the FORTRAN 77 code. At a PPoE that was a defense contractor,
we had to rehost some simulations on a Harris 800/1200 from a CDC
6600. These were what might be termed "legacy" FORTRAN code... in
FORTRAN/66 or FORTRAN IV.
Rich Alderson
> Hi,
> I have to compile some very old Fortran-66 programs, but I do not have
> an IBM host or a TOPS-10/VMS machine.
I was going to point out that Tops-10, TOPS-20, and VMS accounts are available
for free at Living Computer Museum, but having read the entire thread to this
point before responding, I see that that will not solve your issue.
--
Rich Alderson ne...@alderson.users.panix.com
the russet leaves of an autumn oak/inspire once again the failed poet/
to take up his pen/and essay to place his meagre words upon the page...
Peter Flass
The comments about FORTRAN portability are interesting. ISTR before
"C", most programs intended to be portable were written in FORTRAN as
the mos standard and widely-used language.
jmfbahciv
Do you know any physicists?
/BAH
jmfbahciv
> Peter Dassow <z8...@arcor.de> writes:
>
>> Hi,
>
>> I have to compile some very old Fortran-66 programs, but I do not have
>> an IBM host or a TOPS-10/VMS machine.
>
> I was going to point out that Tops-10, TOPS-20, and VMS accounts are
available
> for free at Living Computer Museum, but having read the entire thread to
this
> point before responding, I see that that will not solve your issue.
>
He could try to compile the code with a /[can't remember exact spelling]
FORTRAN66 switch. Well, I just found a FORTRAN manual and it doesn't
mention this switch. drat.
I was going to say to compile the code on a -10 of any flavor just
to see what kinds of problems the code will have. There is a compiler
/SYNTAX switch which won't output any rel code but do a syntax only
check of the FOR code.
If he could generate a PDP-10 exe, is it possible to do a conversion
of PDP-10 instructions to 286 instructions?
Monitor interface code would be later project. But at least he
could find out how much of the FORTRAN code is incompatible with
/F77.
/BAH
Bill Leary
news:iffd37$hrc$1...@news.eternal-september.org...
> The comments about FORTRAN portability are interesting. ISTR before "C",
> most programs intended to be portable were written in FORTRAN as the mos
> standard and widely-used language.
This was my experience.
The problem was that, for business applications, which is mostly what I did,
there was a different way to handle character data for each implementation.
Well, not literally of course, but it sure seemed like it every time I had
to port something.
- Bill
sidd
>>
> These programs calculate the attenuation of an oscillation, and it's
not
> only a sinus which calms down to zero ;-)
i take it that you are solving a differential equation ?
A Runge-Kutta by any chance ?
hanc...@bbs.cpcn.com
> > Just out of curiosity, what are these FORTRAN/66 programs doing that is
> > important enough to warrant compiling on a PC???
>
> These programs calculate the attenuation of an oscillation, and it's not
> only a sinus which calms down to zero ;-)
If there isn't a great deal of code involved, it may be easier to
rewrite the programs into a modern Fortran that can be more easily
compiled to create .EXE files. The rewrite effort might be easier
than trying to find a usable compiler and making it work. I wonder
how much code there is overall, and how much of it is specific to
Fortran/66 and not compatible with later versions. I am in no way a
physicist, but I wonder if such a program is mostly some DO LOOPs with
a bunch of calculation statements.
If the overall code is relatively small, it might be easier to get a
QuickBasic (or BASIC PDS) compiler and rewrite the code for them. As
a last resort, you could use your QBASIC interpreter which should
still be part of your Windows CD, and just send that out with the
code.
I presume the program runs in batch mode. How would the I/O be--
specifying the input and output files for a PC?
Peter Flass
Dredging back in my memory, input and output was to nAm where m was the
number of characters per word, and n was the number of words. If you
specified A1 you got one character per word - portable but not very
efficient.
Peter Flass
> In article<PM0004988...@ac81a7a6.ipt.aol.com>,
> jmfbahciv<See....@aol.com> wrote:
>> Rich Alderson wrote:
>>> Peter Dassow<z8...@arcor.de> writes:
>>>
>>>> Hi,
>>>
>>>> I have to compile some very old Fortran-66 programs, but I do not have
>>>> an IBM host or a TOPS-10/VMS machine.
>>>
>>> I was going to point out that Tops-10, TOPS-20, and VMS accounts are
>> available
>>> for free at Living Computer Museum, but having read the entire thread to
>> this
>>> point before responding, I see that that will not solve your issue.
>>>
>>
>> He could try to compile the code with a /[can't remember exact spelling]
>> FORTRAN66 switch. Well, I just found a FORTRAN manual and it doesn't
>> mention this switch. drat.
>>
>> I was going to say to compile the code on a -10 of any flavor just
>> to see what kinds of problems the code will have. There is a compiler
>> /SYNTAX switch which won't output any rel code but do a syntax only
>> check of the FOR code.
>>
>> If he could generate a PDP-10 exe, is it possible to do a conversion
>> of PDP-10 instructions to 286 instructions?
>
> You can give switches to allow always-execute do, use arithmetic
> if, computed goto, hollerith constants, f66 formatting, old
> equivalence semantics, classic type defaults, and f66 format
> handling. Plus computed assign; a.k.a. "comefrom".
Wouldn't it have been easier if they'd had a -F66 switch?
>
>> Monitor interface code would be later project. But at least he
>> could find out how much of the FORTRAN code is incompatible with
>> /F77.
>
> It is easy to spot, but a lot harder to fix. A lot of these
> programs are state machines that step along using arithmetic
> if statement. easy to spot, a lot harder to port.
Why?
Quadibloc
> i take it that you are solving a differential equation ?
> A Runge-Kutta by any chance ?
If anyone is fooling around with stuff like that, there's a famous
book I think I will recommend. It's titled "Numerical Methods That
Work".
Apparently, when trying to solve differential equations by computer,
it's all too easy to use, by mistake, numerical methods that _don't_
work. Good wishes, good luck - and take care.
John Savard
Quadibloc
> The comments about FORTRAN portability are interesting. ISTR before
> "C", most programs intended to be portable were written in FORTRAN as
> the mos standard and widely-used language.
It is definitely true that FORTRAN was a widely-used language. And it
wasn't a super-fancy language - it didn't come with huge class
libraries - so when programs did have portability problems, it wasn't
like trying to port a C++ program from Windows to the Macintosh or to
the X Window System.
Instead, think of the early dialects of BASIC that required you to put
a line number in front of each line.
FORTRAN was better than that, but it was still in that general class.
You could write programs that did fancy mathematics, and which then
printed simple output. Your installation might have provided you with
special subroutines to draw pictures on a pen plotter, probably made
by Calcomp. Otherwise, well, there was a "tab" function in the FORMAT
statement, so you could draw graphs where the position of an * along
the line of text marked the line you were drawing.
Portability consisted of things like the program depending strongly on
whether single-precision floating-point numbers had 6.23 digits of
precision or 6.56 digits of precision on the machine on which it was
used.
Since time on mainframes was charged for by the second, and they were
usually about as powerful as something like a 386 or a 486 DX, writing
as close to the hardware as possible for maximum efficiency was both a
virtue and a necessity.
John Savard
H Vlems
The Numerical Algorithms Group (located in the UK IIRC) published a
manual for its software package.
The introduction clearly stated that all library programs had been
well designed and thoroughly tested along with the warning that
despite that the user was responsible for selecting the correct
routine for solving a problem. Wasting cpu cycles was considered bad
form in these days ;-)
Hans
Peter Flass
> In article<ifg7f2$oua$2...@news.eternal-september.org>,
> Peter Flass<Peter...@Yahoo.com> wrote:
>> On 12/29/2010 2:31 PM, Morten Reistad wrote:
>>> It is easy to spot, but a lot harder to fix. A lot of these
>>> programs are state machines that step along using arithmetic
>>> if statement. easy to spot, a lot harder to port.
>>
>> Why?
>
> This is a class of programming that was popular sometime around
> 1970 with the right people. They didn't think procedurally, they
> thought in mathematical flows and dependencies.
>
> Some of this code has "exploding call flow", using computed gotos
> and arithmetic ifs to their full potential, using state variables,
> often several; where each statement may have many next hops all
> depending on this state. Add assigned gotos (aka "comefrom") and
> you must rewrite, not port.
>
I'm amazed they'd get rid of this. Like it or not, this stuff was
widely used and still would seem to have a place.
I don't see that an arithmetic IF would be any more problematic than a
logical IF.
Everyone rags on GOTOs, too, but there are places where they're the most
appropriate solution. Assigned GOTOs are the most efficient way to
solve a number of problems. Take the case of a program that has a
number of options. You can have a switch that you test each time thru
the loop to see if a particular option is active, or you can have
assigned GOTOs that are set once in initialization and incurs no
additional overhead to test and branch later. If you need debugging,
have a text field in addition to the assigned GOTO that says what the
setting is without costing much in extra instructions.
For the record I usually try to program as straightforwardly as
possible, and if I do something exotic I usually decorate it with lots
of comments, but it's nice to know you can do the exotic stuff when
necessary.
jmfbahciv
I'm assuming that the OP wants to know the outcome of the existing
code, not an unknown output of a rewrite using a different FORLIB
library.
/BAH
Walter Bushell
<807cdf77-7e4c-48ae...@o4g2000yqd.googlegroups.com>,
Quadibloc <jsa...@ecn.ab.ca> wrote:
People use these without a sanity clause. Hilarity ensues.
--
The Chinese pretend their goods are good and we pretend our money
is good, or is it the reverse?
Walter Bushell
<c883c421-322d-4d98...@w2g2000yqb.googlegroups.com>,
Quadibloc <jsa...@ecn.ab.ca> wrote:
> FORTRAN was better than that, but it was still in that general class.
> You could write programs that did fancy mathematics, and which then
> printed simple output. Your installation might have provided you with
> special subroutines to draw pictures on a pen plotter, probably made
> by Calcomp. Otherwise, well, there was a "tab" function in the FORMAT
> statement, so you could draw graphs where the position of an * along
> the line of text marked the line you were drawing.
You had the "tab" function -- luxury!
But we had data techs who took the printouts and plotted the results by
hand, of course.
Dave Wade
"H Vlems" <hvl...@freenet.de> wrote in message
news:9449daac-5ec3-4c40...@o14g2000yqe.googlegroups.com...
We still get this today. I subscribe to the LTSpice list. LTSpice is a
customized version of the Berkley Spice circuit simulation program. It has
several algorithms for solving the differential equations. Its interesting
to see folks complaining about the simulation breaking down and having to
change the algorithm...
> Hans
Dave
Charlie Gibbs
<c883c421-322d-4d98...@w2g2000yqb.googlegroups.com>,
jsa...@ecn.ab.ca (Quadibloc) writes:
> It is definitely true that FORTRAN was a widely-used language.
Stan Kelly-Bootle described it as "transportable as syphilis".
--
/~\ cgi...@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
Chris Barts
> On 12/29/2010 7:36 PM, Morten Reistad wrote:
>> In article<ifg7f2$oua$2...@news.eternal-september.org>,
>> Peter Flass<Peter...@Yahoo.com> wrote:
>>> On 12/29/2010 2:31 PM, Morten Reistad wrote:
> [snip}
>
>>>> It is easy to spot, but a lot harder to fix. A lot of these
>>>> programs are state machines that step along using arithmetic
>>>> if statement. easy to spot, a lot harder to port.
>>>
>>> Why?
>>
>> This is a class of programming that was popular sometime around
>> 1970 with the right people. They didn't think procedurally, they
>> thought in mathematical flows and dependencies.
>>
>> Some of this code has "exploding call flow", using computed gotos
>> and arithmetic ifs to their full potential, using state variables,
>> often several; where each statement may have many next hops all
>> depending on this state. Add assigned gotos (aka "comefrom") and
>> you must rewrite, not port.
>>
>
> I'm amazed they'd get rid of this. Like it or not, this stuff was
> widely used and still would seem to have a place.
>
> I don't see that an arithmetic IF would be any more problematic than a
> logical IF.
The problem with arithmetic IF these days, of course, is that
approximately nobody knows what they are or how they work. All they see
is an IF statement that can magically choose from three different code
paths, as opposed to every other IF statement in every other language
they've ever seen in their entire lives. This can be solved with a
mini-lecture in a comment, but that kind of implies you add that lecture
to just about every piece of code that uses them. Maybe a macro would
help with this... ;)
> Everyone rags on GOTOs, too, but there are places where they're the
> most appropriate solution. Assigned GOTOs are the most efficient way
> to solve a number of problems. Take the case of a program that has a
> number of options. You can have a switch that you test each time thru
> the loop to see if a particular option is active, or you can have
> assigned GOTOs that are set once in initialization and incurs no
> additional overhead to test and branch later.
So... how do you get a compiler to optimize a branch that can be changed
semi-arbitrarily at runtime? This might be a non-issue in your specific
example, but once you introduce the possibility that all branches of a
certain type are no longer safe to optimize because you can't guarantee
where they'll point, you can't do the kind of static analysis even C
compilers are capable of these days.
> For the record I usually try to program as straightforwardly as
> possible, and if I do something exotic I usually decorate it with lots
> of comments, but it's nice to know you can do the exotic stuff when
> necessary.
Every programmer seems to think like this, but the caveat is that I, for
example, think that creating a jump table out of function pointers is
perfectly straightforward, but someone coming from a different
background might see it as unholy and bizarre voodoo, an abuse of the
language worthy of the International Obfuscated C Code Competition.
Quadibloc
> So... how do you get a compiler to optimize a branch that can be changed
> semi-arbitrarily at runtime?
Remember, to facilitate optimization, an assigned GOTO statement must
also list its possible branch targets - after the variable containing
the pointer, instead of, as in a computed GOTO statement, before the
variable containing the index.
Therefore, the compiler is given the information it needs to do
optimization.
John Savard
Peter Flass
Taken to an extreme, this would imply we should get rid of anything that
isn't C (or Java). Many languages have features that appear odd to
someone who isn't used to them. Rather than a problem, this is an
opportunity for programmers to lose their tunnel vision.
>
>> Everyone rags on GOTOs, too, but there are places where they're the
>> most appropriate solution. Assigned GOTOs are the most efficient way
>> to solve a number of problems. Take the case of a program that has a
>> number of options. You can have a switch that you test each time thru
>> the loop to see if a particular option is active, or you can have
>> assigned GOTOs that are set once in initialization and incurs no
>> additional overhead to test and branch later.
>
> So... how do you get a compiler to optimize a branch that can be changed
> semi-arbitrarily at runtime? This might be a non-issue in your specific
> example, but once you introduce the possibility that all branches of a
> certain type are no longer safe to optimize because you can't guarantee
> where they'll point, you can't do the kind of static analysis even C
> compilers are capable of these days.
>
>> For the record I usually try to program as straightforwardly as
>> possible, and if I do something exotic I usually decorate it with lots
>> of comments, but it's nice to know you can do the exotic stuff when
>> necessary.
>
> Every programmer seems to think like this, but the caveat is that I, for
> example, think that creating a jump table out of function pointers is
> perfectly straightforward, but someone coming from a different
> background might see it as unholy and bizarre voodoo, an abuse of the
> language worthy of the International Obfuscated C Code Competition.
You mean there are people who don't think it's straightforward?
[ :-) ]. This is the problem that arises when people don't have an
assembler background. Again, it's not something I'd do too often, but
it's something that's nice to have in your bag of tricks when it's
appropriate. Often the alternatives require a lot more code.
Your point about optimization is a good one, but, little as I know about
optimization, I'd think a more straightforward test and conditional
branch could cause as many problems.
Walter Bushell
"Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote:
> In article
> <c883c421-322d-4d98...@w2g2000yqb.googlegroups.com>,
> jsa...@ecn.ab.ca (Quadibloc) writes:
>
> > It is definitely true that FORTRAN was a widely-used language.
>
> Stan Kelly-Bootle described it as "transportable as syphilis".
Whereas C and C++ are more like AIDS.
Charlie Gibbs
(Walter Bushell) writes:
> In article <495.50T150...@kltpzyxm.invalid>,
> "Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote:
>
>> In article
>> <c883c421-322d-4d98...@w2g2000yqb.googlegroups.com>,
>> jsa...@ecn.ab.ca (Quadibloc) writes:
>>
>>> It is definitely true that FORTRAN was a widely-used language.
>>
>> Stan Kelly-Bootle described it as "transportable as syphilis".
>
> Whereas C and C++ are more like AIDS.
:-) At this point I usually switch to the automotive analogies
that were making the rounds a while ago. Here's an excerpt:
Assembler: a Formula 1 race car. Very fast, but difficult to
drive and expensive to maintain.
Fortran II: a model T Ford. Once it was king of the road.
Fortran IV: a model A Ford.
Fortran 77: a six-cylinder Ford Fairlane with standard
transmission and no seat belts.
C: a black Firebird - the all-macho car. Comes with
optional fuzzbuster (escape to assembler).