Looking for a real Fortran-66 compatible PC compiler (CP/M or DOS or Windows, doesn't matter)

73 views
Skip to first unread message

Peter Dassow

unread,
Dec 26, 2010, 6:04:52 AM12/26/10
to
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.
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

unread,
Dec 26, 2010, 7:46:33 AM12/26/10
to

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

unread,
Dec 26, 2010, 10:23:32 AM12/26/10
to

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

unread,
Dec 26, 2010, 1:01:14 PM12/26/10
to

"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

unread,
Dec 26, 2010, 2:29:04 PM12/26/10
to
On 26.12.2010 19:01, Dave Wade wrote:
>
> 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
>
Dave, thanks for both URLs.
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

unread,
Dec 26, 2010, 2:36:00 PM12/26/10
to

"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

unread,
Dec 26, 2010, 4:14:47 PM12/26/10
to

How well goes gnu fortran77 work? You might be able to link with mingw32
to get a Microsoft Windows executible.

Bud

Tim Shoppa

unread,
Dec 26, 2010, 4:48:41 PM12/26/10
to

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

unread,
Dec 26, 2010, 4:53:25 PM12/26/10
to
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 at
http://www.z80.eu/for-compiler.html
but this was more CP/M centric ;-)

Regards
Peter

Tim Shoppa

unread,
Dec 26, 2010, 8:08:39 PM12/26/10
to
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.

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

unread,
Dec 27, 2010, 3:36:26 AM12/27/10
to
>   Peter- Tekst uit oorspronkelijk bericht niet weergeven -
>
> - 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

unread,
Dec 27, 2010, 8:22:04 AM12/27/10
to

You could always convert it to PL/I ;-)

http://www.iron-spring.com/free.html

jmfbahciv

unread,
Dec 27, 2010, 8:49:45 AM12/27/10
to

What CPU do you want this to run on? an old compiler would generate
286 machine instructions?

/BAH

Tim Shoppa

unread,
Dec 27, 2010, 12:32:57 PM12/27/10
to
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 ;-)

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.

Message has been deleted

Dave Wade

unread,
Dec 27, 2010, 5:49:39 PM12/27/10
to

"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

unread,
Dec 27, 2010, 11:26:23 PM12/27/10
to
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.


--
+----------------------------------------+
| Charles and Francis Richmond |
| |
| plano dot net at aquaporin4 dot com |
+----------------------------------------+

Charles Richmond

unread,
Dec 27, 2010, 11:28:45 PM12/27/10
to

Just out of curiosity, what are these FORTRAN/66 programs doing
that is important enough to warrant compiling on a PC???

Dave Wade

unread,
Dec 28, 2010, 5:36:15 AM12/28/10
to

"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

unread,
Dec 28, 2010, 9:17:42 AM12/28/10
to
Charles Richmond wrote:
> 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

unread,
Dec 28, 2010, 9:17:41 AM12/28/10
to


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

unread,
Dec 28, 2010, 10:30:07 AM12/28/10
to

"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

unread,
Dec 28, 2010, 12:28:48 PM12/28/10
to
On 28.12.2010 05:28, Charles Richmond wrote:
>> I have to compile some very old Fortran-66 programs, but I do not
>> have an IBM host or a TOPS-10/VMS machine.
>>
>
> 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 ;-)

Regards
Peter

Peter Flass

unread,
Dec 28, 2010, 5:20:57 PM12/28/10
to
^^^^^^^^ Great word! I'll have to
remember it.

>
> /BAH

ArarghMai...@not.at.arargh.com

unread,
Dec 28, 2010, 6:19:48 PM12/28/10
to

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

unread,
Dec 28, 2010, 8:40:30 PM12/28/10
to

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

unread,
Dec 28, 2010, 10:29:47 PM12/28/10
to
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.

--
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

unread,
Dec 29, 2010, 8:29:11 AM12/29/10
to

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

unread,
Dec 29, 2010, 9:38:03 AM12/29/10
to

Do you know any physicists?

/BAH

jmfbahciv

unread,
Dec 29, 2010, 9:38:02 AM12/29/10
to
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?

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

unread,
Dec 29, 2010, 11:20:24 AM12/29/10
to
"Peter Flass" <Peter...@Yahoo.com> wrote in message
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

unread,
Dec 29, 2010, 1:20:34 PM12/29/10
to
On Tuesday 28 December 2010 12:28, Peter Dassow wrote:


>>
> 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

unread,
Dec 29, 2010, 2:24:04 PM12/29/10
to
On Dec 28, 12:28 pm, Peter Dassow <z8...@arcor.de> wrote:

> > 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?

Message has been deleted

Peter Flass

unread,
Dec 29, 2010, 3:56:51 PM12/29/10
to

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

unread,
Dec 29, 2010, 3:59:14 PM12/29/10
to
On 12/29/2010 2:31 PM, Morten Reistad wrote:
> 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?
>
> I have used g77 with some success on old, well tested f66 programs.
> 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?


Message has been deleted

Quadibloc

unread,
Dec 29, 2010, 10:56:23 PM12/29/10
to
On Dec 29, 11:20 am, sidd <s...@situ.com> wrote:

> 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

unread,
Dec 29, 2010, 11:05:40 PM12/29/10
to
On Dec 29, 6:29 am, Peter Flass <Peter_Fl...@Yahoo.com> wrote:

> 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

unread,
Dec 30, 2010, 2:43:24 AM12/30/10
to

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

unread,
Dec 30, 2010, 8:04:35 AM12/30/10
to
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.

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

unread,
Dec 30, 2010, 9:15:52 AM12/30/10
to

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

unread,
Dec 30, 2010, 2:40:38 PM12/30/10
to
In article
<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

unread,
Dec 30, 2010, 2:49:18 PM12/30/10
to
In article
<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

unread,
Dec 30, 2010, 4:43:43 PM12/30/10
to

"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

unread,
Dec 30, 2010, 2:08:30 AM12/30/10
to
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".

--
/~\ 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

unread,
Jan 1, 2011, 7:28:45 PM1/1/11
to
Peter Flass <Peter...@Yahoo.com> writes:

> 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

unread,
Jan 1, 2011, 11:00:11 PM1/1/11
to
On Jan 1, 5:28 pm, Chris Barts <chbarts+use...@gmail.com> wrote:

> 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

unread,
Jan 2, 2011, 7:13:09 AM1/2/11
to

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

unread,
Jan 2, 2011, 10:05:39 AM1/2/11
to
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.

Charlie Gibbs

unread,
Jan 2, 2011, 1:38:33 PM1/2/11
to
In article <proto-358D87....@news.panix.com>, pr...@panix.com
(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).

Charlie Gibbs

unread,
Jan 2, 2011, 1:29:58 PM1/2/11
to
In article <8739pcd...@chbarts.motzarella.org>,
chbarts...@gmail.com (Chris Barts) writes:

> Peter Flass <Peter...@Yahoo.com> writes:
>
>> 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.

Ironically, the latter programmer probably engages in practices which
the former programmer would find equally unholy. Not only that, the
latter programmer probably doesn't bother commenting any of it,
because "my code is so readable that it doesn't need comments."

Peter Flass

unread,
Jan 2, 2011, 2:24:03 PM1/2/11
to
On 1/2/2011 10:05 AM, Walter Bushell wrote:
> 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.
>

Straightforward C is pretty simple to port and/or translate.
Unfortunately these days everyone seems to be looking for opportunities
to show how clever they are, and include lots of tricks. Gnu code is
sometimes the worst. A lot of current stuff is unreadable,

Anne & Lynn Wheeler

unread,
Jan 2, 2011, 2:26:25 PM1/2/11
to
"Charlie Gibbs" <cgi...@kltpzyxm.invalid> writes:
> :-) 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).

just reading Iconoclast ...
http://www.amazon.com/Iconoclast-Neuroscientist-Reveals-Think-Differently/dp/1422115011

mentions that Ford was working in electrical industry and standard
wisdom was that electricity was going to win as power source. Ford
decided leave electricity and develop gasoline engine. Got a two
cylinder engine developed for Model A and sold less than 1000 ... enuf
to stay in business. The major break came by adapting new "french" steel
that was three times stronger with the addition of vanadium (or only
needed 1/3rd the steel and therefor 3 times lighter):
http://en.wikipedia.org/wiki/Vanadium

Reducing the weight by 2/3rds with two cylinder engine ... made the
Model T a significantly more attractive vehicle.
http://en.wikipedia.org/wiki/Model_T

--
virtualization experience starting Jan1968, online at home since Mar1970

Charles Richmond

unread,
Jan 2, 2011, 2:47:34 PM1/2/11
to
On 1/2/11 6:13 AM, Peter Flass wrote:
> On 1/1/2011 7:28 PM, Chris Barts wrote:
>>
>> [snip...] [snip...] [snip...]

>>
>> 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.
>

ISTM that many C compilers would compile a "switch()" statement
with four or more cases... into a jump table in the generated
assembly. With three or less cases, it is *not* too inefficient to
generate the string of "if -- elseif -- elseif".


--
+----------------------------------------+
| Charles and Francis Richmond |
| |
| plano dot net at aquaporin4 dot com |
+----------------------------------------+

Peter Grange

unread,
Jan 2, 2011, 2:49:17 PM1/2/11
to
On 02 Jan 11 10:29:58 -0800, "Charlie Gibbs" <cgi...@kltpzyxm.invalid>
wrote:

>In article <8739pcd...@chbarts.motzarella.org>,
>chbarts...@gmail.com (Chris Barts) writes:
>
>> Peter Flass <Peter...@Yahoo.com> writes:
>>
>>> 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.
>
>Ironically, the latter programmer probably engages in practices which
>the former programmer would find equally unholy. Not only that, the
>latter programmer probably doesn't bother commenting any of it,
>because "my code is so readable that it doesn't need comments."

Back in the days of assembler on the Honeywell 6000 a friend swears he
saw some code which executed backwards, using an XEC (execute single
instruction) and a decrementing index. Of no practical use, except to
make it properly unreadable.

Ahem A Rivet's Shot

unread,
Jan 2, 2011, 2:57:56 PM1/2/11
to
On Sun, 02 Jan 2011 19:49:17 +0000
Peter Grange <pe...@plgrange.demon.co.uk> wrote:

> Back in the days of assembler on the Honeywell 6000 a friend swears he
> saw some code which executed backwards, using an XEC (execute single
> instruction) and a decrementing index. Of no practical use, except to
> make it properly unreadable.

It probably saved a word somehow.

--
Steve O'Hara-Smith | Directable Mirror Arrays
C:>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/

Peter Grange

unread,
Jan 2, 2011, 3:12:09 PM1/2/11
to
On Sun, 2 Jan 2011 19:57:56 +0000, Ahem A Rivet's Shot
<ste...@eircom.net> wrote:

>On Sun, 02 Jan 2011 19:49:17 +0000
>Peter Grange <pe...@plgrange.demon.co.uk> wrote:
>
>> Back in the days of assembler on the Honeywell 6000 a friend swears he
>> saw some code which executed backwards, using an XEC (execute single
>> instruction) and a decrementing index. Of no practical use, except to
>> make it properly unreadable.
>
> It probably saved a word somehow.

Gosh I'd almost forgotten scrimping for memory. The GCOS operating
system had Slave Service Area programs which had to fit in a very
small space (512 words?) I can't remember exactly. I can remember some
of them being re-orged to get the word back which held the datestamp.

Joe Morris

unread,
Jan 2, 2011, 4:27:32 PM1/2/11
to
"Peter Grange" <pe...@plgrange.demon.co.uk> wrote:

> Back in the days of assembler on the Honeywell 6000 a friend swears he
> saw some code which executed backwards, using an XEC (execute single
> instruction) and a decrementing index. Of no practical use, except to
> make it properly unreadable.

If you want to see some ... um, "interesting" coding techniques that make
analysis difficult, read a book (or better, take a class) in malware
detection and analysis. Alternatively, read competently-written
investigation reports of some of the more recent major attacks where
obfustication is repeatedly piled on top of obfustication, foiling (or at
least impeding) signature-based detection, and making it very difficult to
determine just what the attacker actually did.

Joe Morris


Dave Wade

unread,
Jan 2, 2011, 5:44:41 PM1/2/11
to

"Peter Grange" <pe...@plgrange.demon.co.uk> wrote in message
news:0gl1i6t7984s2ql7o...@4ax.com...

Probably provided by Honeywell. There was some really weird code in GCOS3.

Peter Grange

unread,
Jan 2, 2011, 6:45:49 PM1/2/11
to
On Sun, 2 Jan 2011 22:44:41 -0000, "Dave Wade" <dave....@gmail.com>
wrote:

Where do you know GCOS3 from? I worked in Systems Test and Engineering
in Newhouse and later in GC0S3, GCOS8 (briefly), CP6 and even a
smidgeon of Multics support in the UK.

Charlie Gibbs

unread,
Jan 3, 2011, 4:30:51 PM1/3/11
to
In article <0gl1i6t7984s2ql7o...@4ax.com>,
pe...@plgrange.demon.co.uk (Peter Grange) writes:

> Back in the days of assembler on the Honeywell 6000 a friend swears he
> saw some code which executed backwards, using an XEC (execute single
> instruction) and a decrementing index. Of no practical use, except to
> make it properly unreadable.

I once wrote a program that executed backwards by filling memory with
copies of an instruction that decremented the program counter by 8
bytes (the instruction was 4 bytes long). In low memory I placed
a branch to the end of memory so that it looped backwards.

Peter Flass

unread,
Jan 3, 2011, 4:57:32 PM1/3/11
to
On 1/3/2011 4:30 PM, Charlie Gibbs wrote:
> In article<0gl1i6t7984s2ql7o...@4ax.com>,
> pe...@plgrange.demon.co.uk (Peter Grange) writes:
>
>> Back in the days of assembler on the Honeywell 6000 a friend swears he
>> saw some code which executed backwards, using an XEC (execute single
>> instruction) and a decrementing index. Of no practical use, except to
>> make it properly unreadable.
>
> I once wrote a program that executed backwards by filling memory with
> copies of an instruction that decremented the program counter by 8
> bytes (the instruction was 4 bytes long). In low memory I placed
> a branch to the end of memory so that it looped backwards.
>

Too much time on your hands?

Dave Wade

unread,
Jan 3, 2011, 6:50:10 PM1/3/11
to

"Peter Grange" <pe...@plgrange.demon.co.uk> wrote in message

news:6u22i6la3vp0aijec...@4ax.com...

I worked at Refuge Assurance in Manchester for five years, three on their
L66/10, then I went to the Natural Environment Research Council at Bidston,
Birkenhead where they had a L66/60 (I think memory is dim) later upgraded to
a DPS300. NERC was real fun as we had lots of mods in GCOS so we could
connect to JANET and use the local editing facilities in our HP26xx
terminals which made the system some what unreliable.

I went to training at Hammersmith, and also to the TSS internals course in
Amsterdam. When I cam back from that I took one line from out TSS
modifications and the system failures went from one an hour to one a week.
When NERC changed their Honeywell to IBM VM/CMS I was dragged across to IBM.

Vince (Martin?) who used to work in the Phoenix performance labs but left to
set up his own company told me about the gearshift fudge.
He also explained a lot to me about performance and the importance of I/O
tunning. He ran a performance course, also in Amsterdam!.

I do miss those days, computing was fun, and we knew the internals of the
systems in detail.

Dave

hanc...@bbs.cpcn.com

unread,
Jan 3, 2011, 10:25:54 PM1/3/11
to
On Dec 29 2010, 11:05 pm, Quadibloc <jsav...@ecn.ab.ca> wrote:

> 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.

People who did some serious number crunching on old machines told me
the machines, even an 1130, were quite powerful and could do an awful
lot of work.

The big advantage of PCs when they came out was that they were
personal and dedicated to your use, no waiting, no sharing.

If you were lucky enough to get priority use of a mainframe, you could
get a great deal of work done quickly.

Anybody check out the Principles of Operation for today's IBM
mainframes? Lots of new instructions. I would hope the current
Fortran compilers make good use of them.

hanc...@bbs.cpcn.com

unread,
Jan 3, 2011, 10:30:44 PM1/3/11