Fortran - For your amusement -- Re: Lahey FORTRAN for DOS

Author

For your amusement -- Re: Lahey FORTRAN for DOS

Kevin G. Rhoads

2004-11-09, 3:57 pm

All compiled with default options, mostly linked with MS Overlay Linker v3.69
(except MS 4.1, 5.00, 5.10, and the three 32 bit EXEs)

35,116 hello_i1.exe IBM Personal FORTRAN v1.0
21,506 hello_i2.exe IBM Personal FORTRAN v2.0
23,592 hellom32.exe MS Fortran v3.20
28,646 hello330.exe MS Fortran v3.30
28,630 hello331.exe MS Fortran v3.31
17,469 hellom41.exe MS Fortran v4.1
18,327 hellom50.exe MS Fortran v5.00
20,867 hellom51.exe MS Fortran v5.10
31,187 hello_lp.exe Lahey Personal Fortran
23,058 hello_l4.exe Lahey F77L v4.0
101,888 hellofp4.exe MS Fortran Powerstation v4
303,312 hellodf5.exe Digital Visual Fortran 5.1d
327,032 hellodf6.exe Compaq Visual Fortran 6.1
28,001 hellopr1.exe IBM Professional Fortran v1
29,664 hellopr2.exe IBM Professional Fortran v2
32,900 hellorm3.exe RyanMcfarland Fortran v3
-------------------------------------------------

program hello
write (*,7000) ' Hello world.'
stop ' Bye.'
7000 format(A)
end

Paul Van Delst

2004-11-09, 3:58 pm

Kevin G. Rhoads wrote:
> All compiled with default options, mostly linked with MS Overlay Linker v3.69
> (except MS 4.1, 5.00, 5.10, and the three 32 bit EXEs)
>
> 35,116 hello_i1.exe IBM Personal FORTRAN v1.0
> 21,506 hello_i2.exe IBM Personal FORTRAN v2.0
> 23,592 hellom32.exe MS Fortran v3.20
> 28,646 hello330.exe MS Fortran v3.30
> 28,630 hello331.exe MS Fortran v3.31
> 17,469 hellom41.exe MS Fortran v4.1
> 18,327 hellom50.exe MS Fortran v5.00
> 20,867 hellom51.exe MS Fortran v5.10
> 31,187 hello_lp.exe Lahey Personal Fortran
> 23,058 hello_l4.exe Lahey F77L v4.0
> 101,888 hellofp4.exe MS Fortran Powerstation v4
> 303,312 hellodf5.exe Digital Visual Fortran 5.1d
> 327,032 hellodf6.exe Compaq Visual Fortran 6.1
> 28,001 hellopr1.exe IBM Professional Fortran v1
> 29,664 hellopr2.exe IBM Professional Fortran v2
> 32,900 hellorm3.exe RyanMcfarland Fortran v3
> -------------------------------------------------
>
> program hello
> write (*,7000) ' Hello world.'
> stop ' Bye.'
> 7000 format(A)
> end

What the hell, the sun streaming through the window is making me sleepy......

lnx:scratch : pgf90 hello.f90
lnx:scratch : dir a.out
-rwxr-xr-x 1 130K Nov 9 15:22 a.out*
lnx:scratch : ifort hello.f90
lnx:scratch : dir a.out
-rwxr-xr-x 1 409K Nov 9 15:22 a.out*
lnx:scratch : lf95 hello.f90
Encountered 0 errors, 0 warnings in file hello.f90.
lnx:scratch : dir a.out
-rwxr-xr-x 1 13K Nov 9 15:23 a.out*

409K for ifort! Wow.

cheers,

paulv

--
Paul van Delst
CIMSS @ NOAA/NCEP/EMC

Michael Prager

2004-11-10, 3:59 pm

"Kevin G. Rhoads" <kgrhoads@alum.mit.edu> wrote:

>All compiled with default options, mostly linked with MS Overlay Linker v3.69
>(except MS 4.1, 5.00, 5.10, and the three 32 bit EXEs)
>
> 35,116 hello_i1.exe IBM Personal FORTRAN v1.0
> 21,506 hello_i2.exe IBM Personal FORTRAN v2.0
> 23,592 hellom32.exe MS Fortran v3.20
> 28,646 hello330.exe MS Fortran v3.30
> 28,630 hello331.exe MS Fortran v3.31
> 17,469 hellom41.exe MS Fortran v4.1
> 18,327 hellom50.exe MS Fortran v5.00
> 20,867 hellom51.exe MS Fortran v5.10
> 31,187 hello_lp.exe Lahey Personal Fortran
> 23,058 hello_l4.exe Lahey F77L v4.0
> 101,888 hellofp4.exe MS Fortran Powerstation v4
> 303,312 hellodf5.exe Digital Visual Fortran 5.1d
> 327,032 hellodf6.exe Compaq Visual Fortran 6.1
> 28,001 hellopr1.exe IBM Professional Fortran v1
> 29,664 hellopr2.exe IBM Professional Fortran v2
> 32,900 hellorm3.exe RyanMcfarland Fortran v3
>-------------------------------------------------
>
> program hello
> write (*,7000) ' Hello world.'
> stop ' Bye.'
> 7000 format(A)
> end

It is interesting, and it shows that priorities have changed.
Modern computers have 100+ Gb disks, not 360 Kb floppies. On
the other hand, they can do a lot more (though you and I may not
use it).

As a result, runtime libraries are much larger, and that causes
a lot of overhead in executable size. It doesn't seem to matter
to most users (including me these days). When I complained year
ago, one vendor told me it wasn't economically feasible to
modify the linker and libraries to omit routines not used by a
particular program, and that there was very little demand to do
so.

MHP

--
Mike Prager, NOAA, Beaufort, NC
Address spam-trapped; remove color to reply.
* Opinions expressed are personal and not represented otherwise.
* Any use of tradenames does not constitute a NOAA endorsement.

meek@skyway.usask.ca

2004-11-10, 3:59 pm

In a previous article, Paul Van Delst <paul.vandelst@noaa.gov> wrote:
>Kevin G. Rhoads wrote:
>
>What the hell, the sun streaming through the window is making me sleepy......
>
>lnx:scratch : pgf90 hello.f90
>lnx:scratch : dir a.out
>-rwxr-xr-x 1 130K Nov 9 15:22 a.out*
>lnx:scratch : ifort hello.f90
>lnx:scratch : dir a.out
>-rwxr-xr-x 1 409K Nov 9 15:22 a.out*
>lnx:scratch : lf95 hello.f90
>Encountered 0 errors, 0 warnings in file hello.f90.
>lnx:scratch : dir a.out
>-rwxr-xr-x 1 13K Nov 9 15:23 a.out*
>
>409K for ifort! Wow.
>
>cheers,
>
>paulv
>
>--
>Paul van Delst
>CIMSS @ NOAA/NCEP/EMC

WATCOM 10.9 - I get 65536 for windows char. mode executible
and 74834 for 16 bit dos target ..and 97150 for 32 bit dos
(dos4gw extender)

Chris

Kevin G. Rhoads

2004-11-10, 3:59 pm

>Modern computers have 100+ Gb disks, not 360 Kb floppies.

Actually IBM Personal Fortran v1.0 came on three 160k floppies (DOS 1.x,
8 sector/track, single sided); one for compiler first pass, one for
rest of compiler and one for linker & libraries.

I was using it on a PC maxed out to 640k, but DOS1 couldn't use more
than 448k (IIRC). We were running a patched version of DOS1.1 which
would set up the rest of RAM as a ramdrive. With 192k allocated to
DOS and the other 448k as a ramdisk, after booting I'd copy both
compiler phases, linker and the libraries to the ramdrive and
it really flew. The first time I used an XT, the harddrive was
glacial in comparison. Of course, if a program crash took down
DOS, you didn't lose the drive contents (usually).

Of course, certain aspects of that compiler were buggy as all getout.

Michael Prager

2004-11-10, 3:59 pm

"Kevin G. Rhoads" <kgrhoads@alum.mit.edu> wrote:

>I was using it on a PC maxed out to 640k, but DOS1 couldn't use more
>than 448k (IIRC). [...]

I was recalling this morning that one could use a functioning
spreadsheet on a computer with 640K. Now video cards have 64
Mb, and disks can have 8 Mb of cache. Still, program crash.

Plus ca change, plus c'est la meme chose.

--
Mike Prager, NOAA, Beaufort, NC
Address spam-trapped; remove color to reply.
* Opinions expressed are personal and not represented otherwise.
* Any use of tradenames does not constitute a NOAA endorsement.

Richard E Maine

2004-11-10, 3:59 pm

Michael Prager <Mike.Prager.indigo@noaa.gov> writes:

> I was recalling this morning that one could use a functioning
> spreadsheet on a computer with 640K.

A *LOT* less than 640k. The original spreadsheet was Visicalc.
See <http://www.bricklin.com/visicalc.htm> (thanks to google).
Though I never used it much (and I'm still not really "into"
spreadsheets) I'm fairly sure I still have a copy of Visicalc
for my old Apple 2e (which I also still have, though I haven't
powered it up for a year or so).

I don't recall the system requirements. My system was pretty high end
with 128k of memory, but I suspect it might have run ok a 64k (not
640k) system, or even 48k, which was what my Apple 2+ had before I
wire-wrapped my own 16k memory expansion card by hand (too expensive
to buy one at several hundred dollars for the 16k).

I needed the extra 16k to run the UCSD Pascal system, which included
the first Fortran compiler that I had on one of my personal systems.

In my quick skim of the above site, I notice that it says that the
executable for the first Dos version (which was later than the
Apple one) was about 27k in size.. Those who have just been posting
sizes for "Hello, world." might be amused by that comparison.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

E P Chandler

2004-11-11, 3:56 am

Richard E Maine <nospam@see.signature> wrote in message news:<m1mzxpy8wa.fsf@MLMCE0000L22801.local>...
> Michael Prager <Mike.Prager.indigo@noaa.gov> writes:

[snip]
[color=darkred]
> I don't recall the system requirements. My system was pretty high end
> with 128k of memory, but I suspect it might have run ok a 64k (not
> 640k) system, or even 48k, which was what my Apple 2+ had before I

> wire-wrapped my own 16k memory expansion card by hand (too expensive
> to buy one at several hundred dollars for the 16k).

[wow!]

> I needed the extra 16k to run the UCSD Pascal system, which included
> the first Fortran compiler that I had on one of my personal systems.

Apple Fortran was expensive, came on copy protected disks, had no
double precision, and integers were limited (by Pascal's MAXINT) to
-32767..32767, but the software *did* run on a system smaller than a
mainframe.

Richard Maine

2004-11-11, 3:58 pm

epc8@juno.com (E P Chandler) writes:

> Apple Fortran was expensive,

The whole computer was expensive. :-( I had over $6000 in my Apple 2e
(just for hardware). I big chunk of that was the pair of 8" floppy
drives and the controller and case for them; that cost me $2k, but wow
did those floppies hold a lot - a whole meg. With the sturdy case,
hulky power supply, and the 2 drives, the external floppy box was 75
pounds.

> came on copy protected disks, had no
> double precision, and integers were limited (by Pascal's MAXINT) to
> -32767..32767, but the software *did* run on a system smaller than a
> mainframe.

I'd forgotten about the copy-protected disks, but yes, that was an
annoyance. I think I cracked it to make backups (as you say, it
was expensive, and floppies are fragile), but I forget the details.

One other limitation I recall was that it didn't implement backspace
of unformatted files. The thing I most recall about that was that the
documentation claimed that backspace as defined by the standard was
flawed to the extent of being unimplementable on disk files. Since it
was implemented and worked fine on the "big computer" compilers, I
wasn't impressed by the claim that it was unimplementable. No, they
weren't referring to the subtlties of backspace after hitting an
end-of-file. They just hadn't thought of the possibility of putting
record-length trailers.

Me:
[color=darkred]
> [wow!]

Though I have to admit that my wire wrapping was less than professional.
I got it to work, but obviously made one of the classic wire wrap
errors - must had wires routed a little too tightly around some posts.
Eventually that causes the thin insulation between the wire and the post
to go, giving a short. I never found exactly where the short was, but
did observe that all would work fine if I put some tension on the card
in the right direction (probably relieving pressure on the shorting
spot). So yes, for a while, my computer was literally held together
by rubber bands, which were necessary for its functioning. :-)

Eventually things got worse and the rubber bands no longer worked as
well. But by then, prices on the memory cards had dropped enough
that I just went out and bought a commercial one.

--
Richard Maine
email: my last name at domain
domain: summertriangle dot net

Kevin G. Rhoads

2004-11-11, 3:58 pm

>In my quick skim of the above site, I notice that it says that the
>executable for the first Dos version (which was later than the
>Apple one) was about 27k in size.. Those who have just been posting
>sizes for "Hello, world." might be amused by that comparison.

IIRC Digital managed to squeeze Fortran into an 8k PDP-8, but
I don't know how many compiler passes were used.

glen herrmannsfeldt

2004-11-12, 3:56 am

Richard Maine wrote:

(snip)

> One other limitation I recall was that it didn't implement backspace
> of unformatted files. The thing I most recall about that was that the
> documentation claimed that backspace as defined by the standard was
> flawed to the extent of being unimplementable on disk files. Since it
> was implemented and worked fine on the "big computer" compilers, I
> wasn't impressed by the claim that it was unimplementable. No, they
> weren't referring to the subtlties of backspace after hitting an
> end-of-file. They just hadn't thought of the possibility of putting
> record-length trailers.

Record length trailers help, but you can always read from
the beginning until you get to the record before.

(snip)

> Though I have to admit that my wire wrapping was less than professional.
> I got it to work, but obviously made one of the classic wire wrap
> errors - must had wires routed a little too tightly around some posts.

I once knew someone with an 8080 wirewrapped system where one
of the wire wrap posts poked through the tape wrapped around
the power line fuse. As I remember it, he didn't lose too many
chips, but it could have been pretty bad.

-- glen

Klaus Wacker

2004-11-12, 8:57 am

Richard Maine <nospam@see.signature> wrote:
[...]
>
> One other limitation I recall was that it didn't implement backspace
> of unformatted files. The thing I most recall about that was that the
> documentation claimed that backspace as defined by the standard was
> flawed to the extent of being unimplementable on disk files. Since it
> was implemented and worked fine on the "big computer" compilers, I
> wasn't impressed by the claim that it was unimplementable. No, they
> weren't referring to the subtlties of backspace after hitting an
> end-of-file. They just hadn't thought of the possibility of putting
> record-length trailers.

If I remember correctly, there was at least one "big computer" Fortran
implementation which didn't implement backspace of unformatted files:
IBM. Or maybe it was implemented, but by rewind and reread from the
beginning (or form the beginning of the last "physical record"? That
would give rather unpredictable results). RECFM=VBS doesn't have
record-length trailers. I remember clearly that I was told by my
supervisors not to use this feature.

--
Klaus Wacker wacker@Physik.Uni-Dortmund.DE
Experimentelle Physik V http://www.physik.uni-dortmund.de/~wacker
Universitaet Dortmund Tel.: +49 231 755 3587
D-44221 Dortmund Fax: +49 231 755 4547

Jan Vorbrüggen

2004-11-12, 8:57 am

>>One other limitation I recall was that it didn't implement backspace
> If I remember correctly, there was at least one "big computer" Fortran
> implementation which didn't implement backspace of unformatted files:
> IBM. Or maybe it was implemented, but by rewind and reread from the
> beginning (or form the beginning of the last "physical record"? That
> would give rather unpredictable results). RECFM=VBS doesn't have
> record-length trailers. I remember clearly that I was told by my
> supervisors not to use this feature.

VMS has similar problems if you use the default of variable-length records
for the purpose.

Jan

William Clodius

2004-11-12, 8:56 pm

Richard Maine <nospam@see.signature> wrote in message news:<87sm7g2soe.fsf@vega.site>...
> epc8@juno.com (E P Chandler) writes:
> <snip>
> One other limitation I recall was that it didn't implement backspace
> of unformatted files. The thing I most recall about that was that the
> documentation claimed that backspace as defined by the standard was
> flawed to the extent of being unimplementable on disk files. Since it
> was implemented and worked fine on the "big computer" compilers, I
> wasn't impressed by the claim that it was unimplementable. No, they
> weren't referring to the subtlties of backspace after hitting an
> end-of-file. They just hadn't thought of the possibility of putting
> record-length trailers.
> <snip>
Or of keeping a linked list of record-lengths as they are acquired,
either in RAM, or in compiler dependent temporary files on disk, or
post-pending the record lengths to the file (I believe Giles mentioned
that once), or (for some operating systems) associating an "invisible"
descriptor file, or simply being too lazy to think.

E P Chandler

2004-11-13, 3:58 pm

Richard Maine <nospam@see.signature> wrote in message news:<87sm7g2soe.fsf@vega.site>...
> epc8@juno.com (E P Chandler) writes:
>
>
> The whole computer was expensive. :-( I had over $6000 in my Apple 2e
> (just for hardware). I big chunk of that was the pair of 8" floppy
> drives and the controller and case for them; that cost me $2k, but wow
> did those floppies hold a lot - a whole meg. With the sturdy case,
> hulky power supply, and the 2 drives, the external floppy box was 75
> pounds.
>
>
> I'd forgotten about the copy-protected disks, but yes, that was an
> annoyance. I think I cracked it to make backups (as you say, it
> was expensive, and floppies are fragile), but I forget the details.
>

The annoyance went beyond not being able to create backup disks. The
compiler file had two non standard disk sectors. After reading these
raw sectors in and writing them back out as standard disk sectors, it
was then possible to move files around from their usual positions on
the distribution disks to create a practical working system. Perhaps
the software vendor should have spent more time implementing language
features rather than instituting copy protection that actually
interfered with the legitimate user of the product.

glen herrmannsfeldt

2004-11-15, 8:56 am

Klaus Wacker wrote:

(snip)

> If I remember correctly, there was at least one "big computer" Fortran
> implementation which didn't implement backspace of unformatted files:
> IBM. Or maybe it was implemented, but by rewind and reread from the
> beginning (or form the beginning of the last "physical record"? That
> would give rather unpredictable results). RECFM=VBS doesn't have
> record-length trailers. I remember clearly that I was told by my
> supervisors not to use this feature.

I am pretty sure OS/360 Fortran can do BACKSPACE, and subsequent
Fortran compilers, also. I believe it is done by the OS
(access methods). I don't know how much overhead there is to doing it.

The BSP macro instruction:

http://publibfp.boulder.ibm.com/cgi.../igg3d500/3.2.2

There are restrictions on its use, but I believe they are
satisfied by Fortran unformatted (VBS) files. The track overflow
features allows non-VBS blocks to span track boundaries, and
is processed by the hardware. VBS allows blocks larger than
a physical disk track to be processed by software using block
and record headers. The system knows which tracks are
allocated to the data set, and which block of the track it is on.

Well, for records within a block it is done by the deblocking
code which BSAM doesn't do, so it would be within the Fortran
library. Across block boundaries the BSP macro described above
would be used.

http://publibfp.boulder.ibm.com/cgi...gt1d405/3.2.3.2

The record header includes the block length, and also whether
it is the first, last, or only segment of a logical record.
(I believe that VBS was created for Fortran unformatted files.)

-- glen

keith bierman

2004-11-16, 3:57 pm

Kevin G. Rhoads wrote:
> All compiled with default options, mostly linked with MS Overlay Linker v3.69
29,664 hellopr2.exe IBM Professional Fortran v2
> 32,900 hellorm3.exe RyanMcfarland Fortran v3
> -------------------------------------------------
>
> program hello
> write (*,7000) ' Hello world.'
> stop ' Bye.'
> 7000 format(A)
> end

chiba:/home/khb>f90 -V bork.f
f90: Forte Developer 7 Fortran 95 7.0 2002/03/09 Solaris/SPARC)
chiba:/home/khb>ls -l a.out
-rwxrwxr-x 1 khb staff 6.2K Nov 16 11:36 a.out*

Sponsored Links