forums.silverfrost.com

[JohnCampbell]

Lahey Fortran 95 documentation does refer to this problem.
I recall that Lahey F77 did automatically upgrade constants to double precision, such as " x = 0.6 "

Lahey/Fujitsu Fortran 95 Language Reference :Revision D,
Appendix A : Fortran 77 Compatibility states:

"Standard Fortran 90 is a superset of standard Fortran 77 and a standard-conforming Fortran 77 program will compile properly under Fortran 90. There are, however, some situations in which the program’s interpretation may differ.
• Fortran 77 permitted a processor to supply more precision derived from a REAL constant than can be contained in a REAL datum when the constant is used to initialize a DOUBLE PRECISION data object in a DATA statement. Fortran 90 does not permit this option."

I have experienced the changes to the precision of constants in old code. It has been a significant annoyance when checking transferring code to newer compilers. This problem also was mitigated when transferring from CDC to mini, with constants for REAL*8 being upgraded. Pr1me FTN compiler also provided this support.
( The other significant issue was the loss of 80 bit registers when moving to SSE vector instructions )

[mecej4]

John, there is no DATA statement in your example code ( http://forums.silverfrost.com/posting.php?mode=quote&p=25703 ), so the Lahey extension (of considering a constant to be DOUBLE PRECISION based on the number of digits in the mantissa being sufficiently large, with or without a "Dnn" exponent field) would not apply.

[JohnCampbell]

My recollection is that the increased precision of constants extended to statements like " x = 0.6".

There was support from the mini computer compiler writers to address the precision problems when using double precision/real*8, as a lot of their market was from users of CDC developed software, which they needed to prove could run on their mini. This issue became more significant when moving to F95, which effectively banned this feature.
I am surprised that the Silverfrost F77 doesn't show this feature.

I have tried unsuccessfully to find my 16-bit and 32-bit F77 compilers or documentation. ( which was probably paper copies only )

This is of historical interest only, as the Fortran standard has long been fixed in this approach (nearly 30 years!), requiring precision to now be appropriately addressed.

[mecej4]

John C., there were at least three Lahey Fortran 77 compilers that I used in the past:

1. LFP77 ("personal"); small memory model (64 K code, 64 K data)

2. LF77; 20-bit address range, 16 bit code

3. EM32; uses a DOS extender (TNT? PharLaps?) to access up to 16 MB data

I still probably have some of those on old floppies. Are you referring to one of these? Which?

Thanks.

[JohnCampbell]

mecej4,

I certainly used LF77 (640k) and EM32 ( a few mb of memory )
This was after using Microsoft F77 (640k), with HUGE attribute for arrays larger than 64k.
Somewhere in there I used an overlay linker with Microsoft F77 & LF77(?).
After this I then moved from EM32 to FTN77 and better graphics.
In parallel I was still using Pr1me FTN (not F77) then Apollo and Sparc.
Not much Vax, as their Fortran was too different. (What a loss when Apollo went to HP).
I recall that Pr1me FTN was very accommodating, as was Apollo, so I'd expect they would have provided higher precision constants.

I thought Lahey applied 80 bit precision to constants. Their documentation for F95 certainly recognises the issue.

I am surprised Salford FTN77 did not, although you are showing it does not now.
This wasn't the only precision hickup, as moving from x87 to SSE instructions certainly lost precision, which had to be accepted when vector instructions became more common.

The net result was that for testing new compilers, I had to write code to compare runs and report the different round-off errors to determine if the compiler switch had some errors. It now becomes even more interesting with multi-thread results.

I started moving code from CDC to Pr1me in 1975. Pr1me were very keen to help in those days with benchmarks. It is amazing to recall the computer costs in those days, and especially the frequency of service technicians being called to repair disks. We did partial disk backups each day and a full backup each week, and probably a rebuild every 2 months. We had a 600 mb, 2 x 300 mb and 1 x 80 mb drives for storage with 32 mb for paging / virtual memory. (In the last year I have been cleaning out a lot of disk to memory based solvers and replacing then with memory to cache solvers. Interesting the similarity in now treating memory as we considered the paging disks of 40 years ago)

My disappointment is that with AVX registers/instructions we don't have a hardware supported real*12 or real*16 ( no interest in real*12 ! )

[LitusSaxonicum]

[mecej4]

[JohnCampbell]

[JohnCampbell]

[LitusSaxonicum]

John,

Then I suggest trying the old version with disk I/O on a machine with the new generation of M2 MVMe SSDs. You could get some idea of the benefit simply by using a SATA SSD for the temporary files, (which is a simple trial, costing about £100), and if this gives sensible speed-ups, remember that the NVMe SSD is many times faster than a SATA SSD (but may require a different hardware).

Eddie