Fortran Source, Fall 1998
Volume 14, Issue 2
Make Way for LF95!
The first Fortran language system produced by the Lahey/Fujitsu Fortran Alliance.
Field tests show that Lahey/Fujitsu Fortran 95, LF95, is as solid as any compiler we've ever released. It generates fast code, diagnoses problems as well as or better than LF90, and offers new porting features such as quad-precision data types and VAX structures.
LF95 is available in two editions: LF95 PRO and LF95. Both editions offer the following new features: faster execution speed for most programs that use Fortran 90 features; intrinsic, quad-precision data types; full Fortran 95 support; more support for non-standard, legacy features, including Hollerith data and VAX structures; FDB, the Fujitsu command-line debugger; C-language support in Lahey ED; and faster compile speed. LF95 PRO includes all of LF95 and adds the Fujitsu C Language System, Visual Analyzer, and Scientific Subroutine Library, and unlimited phone support (in addition to the free, unlimited e-mail, fax, and postal mail support included with LF95).
How does LF95 differ from LF90?
Pricing The list price of LF95 PRO is US$795. LF95 is US$595. Through January 31, 1999, we're offering a competitive upgrade to LF95 PRO for US$595 and to LF95 for US$395. You can update to LF95 PRO from LF90 v4.5 for US$195 or from earlier versions of LF90 for US$295. Call Lahey or your local reseller and order today!
Fortran Productivity Tools for Windows
Make your Fortran program a Windows Fortran program with new versions of these great user-interface and graphics tools. They're all compatible with Lahey/Fujitsu Fortran 95 and available from Lahey. For more information, visit us at www.lahey.com or contact us at 800-548-4778, 702-831-2500, or email@example.com.
Dialog Box enhancements
Over 100 new features
Visit www.indowsway.com/home.htm for details, demos, and a free evaluation version.
GINO-F Bundle v4.2
The new GINO-F Bundle is now available as an F90 binding as well as the familiar F77 binding. The F90 binding includes long, descriptive names, derived types, pre-defined constants, and optional arguments. The F90 versions of GINO are supplied with a completely new set of documentation and on-line help files, but also include the F77 short-name interface for those customers who wish to run existing programs.
The majority of new functionality in v4.2 has gone into GINOMENU, including new features such as:
Text and value entry grids
Visit www.bradassoc.co.uk for details.
Winteracter v2.0 will be available on November 27th. In addition to adding LF95 support, major new features will include:
Calcomp HCBS, Lahey Video
Graphics, and Graphoria compatibility layer
Text file printing
These are just some of the many features in this 6-monthly update. Further details of these and other new v2.0 features will be posted at the Interactive Software Services Ltd. web site, www.demon.co.uk /issltd, on the release date.
Porting to LF90 or LF95 from Other Platforms
by Howell Johnson
The problems encountered most frequently when porting code to LF90 or LF95 from another platform are those concerning file I/O and floating point operations.
Let's start with files. Different Fortran compilers use different conventions for unformatted (binary) file output formats; they are not standardized. They also use different conventions for marking the start and end of records. This is why files containing the same "data" written by programs from different compilers will have different sizes and different contents.
Lahey file formats are described in Appendix A of the LF90 and LF95 User's Guide, and in Chapter One of the Language Reference (see the section on "Input/Output").
In addition, data can be stored in either "big endian" or "little endian" format in a file, depending on the machine architecture on which the program is run. On PC/Intel architectures, data is stored in "little endian" form, where the low-order byte is followed by the high-order byte (the "little end" comes first, hence "little endian" -- at least that's the way I see it). Machines built with the DEC architecture (VAX, Alpha, etc.) use the "big endian" form. The reason for this is that file contents reflect the way data is stored internally in RAM.
Converting unformatted files with LF90 or LF95 usually involves opening the file using the specifier ACCESS="TRANSPARENT" (a nonstandard Lahey extension), which allows the file to be read a byte at a time with no assumptions about headers or record delimiters. This allows one to have the same degree of control as when handling files in the C language. For an example of this technique, see the file SEQUNF.F90, provided in the LF90 and LF95 installations.
The big-endian/little-endian problem applies equally to formatted and unformatted files. There are several techniques for dealing with this situation. One way would be to write a program that opens the file with transparent access, reads data into a 2-byte integer (kind=2 for LF90), and swaps the bytes using the ISHFTC( ) intrinsic. Another way would be to use an operating system utility such as the Unix DD utility. Transferring the file over a network using FTP in binary mode would also swap the bytes as necessary. Here is a sample Fortran program for performing the byte swap:
Program byte_swap integer (kind=2) myword open (unit=11,file='infile',access='transparent',err=50) open (unit=12,file='outfile',access='transparent') 10 read (11,end=50) myword myword = ishftc(myword,8,16) write (12) myword goto 10 50 stop end programFormatted files on different machines may differ in the way that lines of text are terminated. They may be terminated with a CR/LF pair, as is typical with text files on DOS and Windows operating systems, or they may be terminated with a single CR or a single LF. These differences can sometimes cause problems when reading such files in an LF90 or LF95 program. The simplest way to convert these files is to open them in the Microsoft EDIT editor (type EDIT at the dos prompt) and do a file save. Transferring the file via FTP in ASCII mode will also substitute the appropriate line terminators.
Now that we've covered the common issues related to file I/O, we can discuss floating-point operations. It turns out that floating-point, base-10 operations carried out on machines with binary (base-2) architectures and finite precision don't always turn out the way we would intuitively expect them. This is a fairly deep topic in itself, and is the subject of an excellent paper by Bruce Bush, itled "The Perils of Floating Point," available at www.lahey.com/float.htm. We can, however, discuss here the more common issues that pertain to porting.
As a rule, different compilers and architectures will differ slightly in their representation and manipulation of floating-point values, namely in the number of bits used to represent the values and in the round-off behavior associated with certain operations. Lahey compilers use the IEEE format for representing floating-point numbers, which is required for using the Intel numeric coprocessor (i.e., a single-precision REAL uses bits 0-23 for the mantissa, bits 24-30 for the exponent, and bit 31 for the sign). Some compilers also perform code optimization, which can also introduce slight differences. The end result of this phenomenon is that results of numerical calculations may differ noticeably from expected values, or that a program's logical flow may be altered inexplicably.
When numerical results are different, it is usually because calculations are carried near a point of instability (i.e., the intermediate results approach the limits of the machine's precision), and the effect is amplified by subsequent calculations. This indicates that the calculation should be modified to accommodate the finite precision of the machine. In general, it is possible to avoid instabilities and potential bifurcation points by making use of mathematical identities and re-ordering of calculations. One example that comes to mind is the inverse Radon transform, used in reconstructing CAT-scan images. The formula for the inverse transform involves a singularity, while the actual numeric calculation makes use of back-projection combined with a filter (convolution or Fourier transform).
Certain intrinsic functions can produce large differences in output based on small differences in input. For example, suppose you are converting dollars and cents float values to integer by multiplying by 100.0 and using the INT( ) function. Because certain floating-point values cannot be represented exactly in binary, there will be cases where the result is truncated downward and the result is 1 less than the expected value. This particular example is an insidious case, because you cannot see what is happening unless you print the intermediate result in its full precision. This example is based on an actual tech support case, where the program ran fine on an older mainframe, but produced wrong results when run on an Intel-based machine, regardless of which compiler was used. The solution was to use NINT( ) rather than INT( ).
The more common result of differences in numerical precision is the case where the program's logical flow is altered due to comparison of floating-point values in an IF statement. This is the rationale behind a commonly witnessed warning in Lahey compilers:
WARNING: Floating-point comparisons for equality may produce inconsistent results.
Ideally, one should correct this situation by changing the offending expression to a comparison for inequality with a machine- and magnitude-dependent epsilon value (see Bruce Bush's paper for explanation). However, most of us are too busy or under too much pressure to pursue such a remedy. The alternative, often just as effective, is to truncate the extra precision of intermediate results by compiling with the -ap switch (not available in LF95) and, in some cases, turning off optimization by compiling with -o0.
Greetings Fortran Programmer,
There are milestones along the way that occasionally bolster our confidence that we know where we are going, and also remind us of important decisions - I think Fujitsu agreeing to have Lahey market its Fortran 95 outside of Japan is one of those milestones.
In 1995, Lahey became aware of Fujitsu's quality in the first review of Fortran 90 implementations; the review appeared in the May-June issue of Fortran Journal. In reviews that have followed, Fujitsu has been among the leaders, if not the leader, in quality. While Lahey has been working with Fujitsu to create LF95, they have strengthened this perception.
Lahey has a Fortran suite of more than 8,000 tests. We have run those tests and Fujitsu is fixing any reported problems. Therefore, if you have been using LF90 for your Fortran programs and have reported bugs, you can have high assurance that your programs will execute correctly. License LF95 with confidence.
1) Approximately 1,800 source files, each a program unit less than 250 lines, poorly documented, spaghetti code, much of it written prior to FORTRAN 77. The problem was to get the code up and running on the PC by September. An important, known problem going in was the use of Hollerith data, especially in initialization.
Because the program units were small, it was "easy" to get a fixed-price proposal with a schedule to get every source file in meaningfully better shape with respect to Fortran 90. Lahey included in its fixed-price proposal: A) Modernize and clean up the code. B) Identify and inventory remaining problems, including possibly-buggy code. C) Submit a fixed-price proposal with schedule to solve B. D) Visit the site for a week to review A, present B, and discuss C. During this first phase, there was no intent to solve the Hollerith data problem except in the most local circumstances and agreed-upon date, while still possible, was not committed to.
Lahey was not awarded this contract. It was awarded to someone who agreed to solve the Hollerith problem by September for approximately three times the Lahey quote (not an excessive amount in my judgment). Later we were told that it might have turned out better if the contract had been awarded to Lahey.
2) Bill sent me 27 files containing code (11), data (9), and Job Control Language (7), plus the output from successful runs (very important). The documentation consisted of a pencil sketch of the job flow and how the JCL, Fortran source, and data files plus intermediate files were connected, plus an occasional comment in the code. Bill agreed to allocate $1,000 at-a-time; he would evaluate progress after I had spent at most $1,000 and decide how much, if anything, he wanted to invest in the next session. We agreed to a finish date.
Bill and I finished the project on time. I created four source files containing a total of 1,216 lines, eliminated every system dependency but one, added Fortran I/O statements for every file, made the direct access file I/O Fortran standard, modernized and cleaned up the code, fixed two bugs, did a little code commenting, and created a DOS batch file to run the job.
Bill and I agreed to do a second port. I created four source files (a total of 923 lines) whose code was highly similar to the first. The total cost for both ports was $6,500.
If you are considering porting Fortran code to the PC, I hope the above examples will encourage you to discuss your project with Lahey -- I enjoy porting. It's worth noting that except for system code (which can usually be minimized), ported Fortran code that executes in DOS can be compiled and executed elsewhere.
I'll be gone until early November to lead workshops in Reston, Virginia, U.S.A.; outside London, England; and in Munich, Germany. I lead the November workshop in Reno. It would be nice to meet you along the way.
New ISV Products
The following are new Independent Software Vendor (ISV) products compatible with Lahey Fortran language systems. Please contact the vendor for availability.
Speakeasy supports all standard types of structured objects -- scalars, 1-D and 2-D arrays, vectors, matrices, sets, and time series. Speakeasy solves arithmetic expressions using these objects.
Speakeasy's high-level language is well suited to the development of powerful, customized applications. Using the intuitive Speakeasy language, non-programmers can develop new operations and applications with mouse-driven front ends. Speakeasy is compatible with LF90.
Speakeasy Computing Corporation
Please check www.lahey.com for the latest information on Lahey ISV products. If you are interested in becoming a Lahey ISV or know of a product that should be listed, please contact:
Learning Fortran 90/95 has never been better. Our traveling team of trainers, Joe Chirieleison, Tom Lahey, and Tim Zeisloft will hit the road this fall with a full lineup of Fortran 90/95 Workshops. Workshop sessions are hands-on; you work through porting one of your own FORTRAN 77 programs to Fortran 90/95 using Tom Lahey's porting recipe. The Workshop is a three-day, intensive training program with time to implement new techniques in class and share ideas with fellow participants. The remaining Fall/Winter workshop schedule is as follows:
Essential LF90 v4.0 was released on October 19, 1998. Version 4.0 offers the ability to create Windows applications and includes the new Lahey ED v3.80 development environment, the Winteracter Starter Kit for creating Windows user interfaces and displaying graphics, and a some changes to the Essential Fortran language. Please visit Essential LF90 v4.0 for details.
If you don't need IMSL's procedure-name compatibility, try Fujitsu's Scientific Subroutine Library, included with LF95 PRO.
Nothing is free these days - or is it? To perpetuate the use of Fortran at universities and elsewhere, Lahey has put a free, downloadable version of our educational compiler, Essential Lahey Fortran 90, on our web site.
Essential Lahey Fortran 90 is for students, teachers, scientists, and engineers who want to write programs using the modern features of Fortran 90. Essential Lahey Fortran 90 removes obsolescent Fortran 90 features (arithmetic IF and assigned GO TO, for example). It eliminates clutter such as the optional comma after a DO statement. Essential Lahey Fortran 90 imposes requirements where the Fortran 90 standard grants options (for example, IMPLICIT NONE is required in every program unit). And, Essential Lahey Fortran 90 eliminates storage association (COMMON, EQUIVALENCE, and implicit procedure interfaces). Essential Lahey Fortran 90 programs are easily maintained and run under the full Lahey Fortran 90, Lahey/Fujitsu Fortran 95, or any other compiler that supports the Fortran 90 standard.
Help us spread the word - tell everyone about the free Fortran language system!
Lahey Fortrans Year 2000-compliant?
However, Lahey compilers do offer a date subroutine called DATE( ), which returns the current system date in MM/DD/YY format. If you have code that calls DATE( ), and that code assumes that the century is 1900, you may have Year 2000 problems. To help, Lahey Fortran 90 issues a warning that DATE( ) doesn't return a 4-digit year.
Lahey/Fujitsu Fortran 95, Lahey Fortran 90, and Essential Lahey Fortran 90 include the Fortran 95 standard DATE_AND_TIME subroutine. DATE_AND_TIME returns a 4-digit year. We recommend changing all code that uses DATE to use DATE_AND_TIME instead. DATE_AND_TIME is not included with our FORTRAN 77 compiler, EM/32. We recommend that EM/32 owners upgrade to LF95.
Q: Is there any way to reduce the size of Windows executables created by LF90?
-reclass seg _lc_COMMONBLOCK BSSwhere COMMONBLOCK is the name of an uninitialized common block. This switch places the uninitialized common block in the BSS segment. For example:
lf90 myprog.for -reclass seg _lc_MYCOMMON BSScauses a smaller executable to be generated for the following code:
program myprog common /mycommon/ x(1000000) endMultiple large, uninitialized common blocks will require that the -reclass seg switch be used multiple times.
In a future patch, LF90 will automatically place uninitialized common blocks in the BSS segment so you won't have to use this switch. LF95 doesn't have this problem.
running in ED4W I get the error, "Can't find SAIGPIPE.386 in SYSTEM.INI file."
DEVICE=<path>\SAIGPIPE.386where <path> is the location of the SAIGPIPE.386 file.
Q: When calling a Lahey-compiled DLL from a Visual Basic program, I receive a run-time error saying the DLL cannot be found even though the DLL is where it should be. How can I fix this?
Q: How can I pass an array of strings from Visual Basic to Fortran?
Q: Does LF90 work on Windows 98?
Q: When compiled with LF95 and the -chk switch, my code runs much more slowly than when compiled with LF90. Why?