lahey/fujitsu fortran 95 user’s guidelahey/fujitsu fortran 95 user’s guide 1 1 getting started...

Lahey/Fujitsu Fortran 95 User’s GuideRevision D.03

CopyrightCopyright © 1995-2004 Lahey Computer Systems, Inc. All rights reserved worldwide. Copyright © 1999-2004FUJITSU, LTD. All rights reserved. Copyright © 1994-2004 Microsoft Corporation. All rights reserved. Thismanual is protected by federal copyright law. No part of this manual may be copied or distributed, transmitted,transcribed, stored in a retrieval system, or translated into any human or computer language, in any form or byany means, electronic, mechanical, magnetic, manual, or otherwise, or disclosed to third parties.

TrademarksNames of Lahey products are trademarks of Lahey Computer Systems, Inc. Other brand and product names aretrademarks or registered trademarks of their respective holders.

DisclaimerLahey Computer Systems, Inc. reserves the right to revise its software and publications with no obligation ofLahey Computer Systems, Inc. to notify any person or any organization of such revision. In no event shall LaheyComputer Systems, Inc. be liable for any loss of profit or any other commercial damage, including but not lim-ited to special, consequential, or other damages.

Lahey Computer Systems, Inc. 865 Tahoe Boulevard

P.O. Box 6091Incline Village, NV 89450-6091

(775) 831-2500Fax: (775) 831-8123

http://www.lahey.com

Technical Support(775) 831-2500 (PRO version only)[email protected] (all versions)

Table of Contents
Getting Started........................................1
System Requirements ...................................... 1Manual Organization ....................................... 1Notational Conventions ................................... 2Product Registration ........................................ 2Installing Lahey/Fujitsu Fortran 95 ................. 3Network Installation ........................................ 4Maintenance Updates ...................................... 5Uninstalling LF95............................................ 6Repairing LF95................................................ 6Building Your First LF95 Program ................. 7

Generating the Executable Program............ 7Running the Program .................................. 7

What’s Next? ................................................... 8Other Sources of Information .......................... 8

Developing with LF95...........................11The Development Process ............................. 11How the Driver Works .................................. 12Running LF95................................................ 12

Filenames .................................................. 13Options ...................................................... 14Driver Configuration File (LF95.FIG) ...... 14Command Files ......................................... 14Passing Information................................... 15Return Codes from the Driver ................... 15Creating a Console-Mode Application...... 15Creating a Windows GUI application ....... 16Creating a WiSK Application ................... 16Creating a 32-bit Windows DLL............... 16Creating a static library ............................. 17OpenGL Graphics Programs ..................... 17Controlling Compilation ........................... 19Errors in Compilation................................ 19

Compiler and Linker Options ........................ 20 Linking.......................................................... 39

Additional Linker Options ........................ 39Linking Fortran 95 Modules ..................... 39Object File Processing Rules..................... 40Linking Libraries....................................... 40

Recommended Option Settings......................40

Mixed Language Programming ...........43Dynamically linked applications....................44

Supported language systems......................44Declaring calling conventions ...................45Building Fortran DLLs ..............................46Building Import Libraries ..........................47Delivering Applications with LF95 DLLs.48

Statically linked Fortran and C applications ..48Calling Conventions ..................................49Argument Passing ......................................50Variable Type Correspondence .................51

Fortran Calling Fortran DLLs ........................59Fortran and C applications .............................59

Fortran calling C DLLs..............................59C Calling Fortran DLLs.............................60Passing Data...............................................61

Microsoft Visual Basic Information...............61Visual Basic calling Fortran ......................61Declaring your Procedure in Visual Basic.62Passing Character Data in Visual Basic.....62Passing Arrays in Visual Basic ..................62

Borland Delphi Information...........................63Delphi Calling Fortran ...............................63Fortran Calling Delphi DLLs.....................63Declaring your Procedure in Delphi ..........64Passing Character Data in Delphi ..............64Passing Arrays in Delphi ...........................65

Calling Fortran DLL’s from .NET Applications65

Calling LF95 DLLs from Microsoft C# ....65Calling LF95 DLLs from Microsoft Visual Basic .NET.................................................66Calling LF95 DLLs from Microsoft Visual C++ .NET ..................................................67

Calling the Windows API ..............................68Calling assembly language procedures ..........71

LF95 Conventions......................................71Passing Arguments to Subroutines ............72

Lahey/Fujitsu Fortran 95 User’s Guide i

Contents

Returning Values from Functions ............. 80

Editing and Debugging with ED.......... 85Setting Up and Starting ED ........................... 85

Startup ....................................................... 85Exiting ED..................................................... 86The ED Screen............................................... 86

The Menu Bar ........................................... 86The Status Bar ........................................... 87The Text Bar ............................................. 87Toolbars .................................................... 87The Window Bar ....................................... 88

Getting Help .................................................. 88Managing Files .............................................. 88

Creating A File From Scratch ................... 88Opening A File.......................................... 89

Syntax Highlighting ...................................... 90Navigation ..................................................... 90

Previous/Next Procedure........................... 90Function/Procedure List ............................ 90Find ........................................................... 91Matching Parentheses and Statements ...... 91

Editing ........................................................... 91Undo and Redo.......................................... 91Extended Characters ................................. 91Blocks........................................................ 92

Coding Shortcuts ........................................... 92Templates .................................................. 92Smartype ................................................... 93Case Conversion ....................................... 93Code Completion ...................................... 93

Compiling from ED....................................... 94Compiling Your Program......................... 94Locating Errors ......................................... 94Changing Compiler Options ..................... 95

Debugging ..................................................... 95Starting the Debugger ............................... 96Running Your Program............................. 97Running a Line at a Time.......................... 97Setting Breakpoints ................................... 97Displaying the Values of Variables .......... 99Changing the Values of Variables .......... 100Reloading your Program ......................... 100

Configuration ..............................................100

Command-Line Debugging with FDB103Starting FDB ................................................103Commands ...................................................103

Executing and Terminating a Program....104run arglist ...........................................104Run.....................................................104kill ......................................................104param commandline arglist................104param commandline...........................104clear commandline.............................104quit .....................................................104

Shell Commands......................................104cd dir ..................................................104pwd.....................................................104

Breakpoints..............................................105break [ ’file’ ] line..............................105break [ ’file’ ] funcname ....................105break *addr ........................................105break...................................................105breakon [#n] .......................................106breakoff [#n] ......................................106condition #n expr ...............................106condition #n .......................................106oncebreak ...........................................106regularbreak "regex" ..........................106delete location ....................................106delete [ ’file’ ] line .............................106delete [ ’file’ ] funcname ...................106delete *addr........................................106delete #n.............................................106delete ..................................................107skip #n count ......................................107onstop #n cmd[;cmd2;cmd3...;cmdn] 107show break .........................................107

Controlling Program Execution...............107continue [ count ] ...............................107silentcontinue [ count ] ......................107step [ count ] ......................................107silentstep [ count ]..............................107stepi [ count ] ....................................107silentstepi [ count ].............................108next [ count ] ......................................108

ii Lahey/Fujitsu Fortran 95 User’s Guide

Contents

silentnext [ count ] ............................. 108nexti [ count ]..................................... 108silentnexti [ count ] or nin [ count ] ... 108until .................................................... 108until loc.............................................. 108until *addr.......................................... 108until +|-offset ..................................... 108until return ......................................... 108

Displaying Program Stack Information... 109traceback [n] ...................................... 109frame [#n] .......................................... 109upside [n] ........................................... 109downside [n] ...................................... 109show args ........................................... 109show locals ........................................ 109show reg [ $r ].................................... 109show freg [ $fr ] ................................. 109show regs ........................................... 109show map........................................... 109

Setting and Displaying Program Variables ...110

set variable = value ............................ 110set *addr = value................................ 110set reg = value.................................... 110print [ [:F] variable [ = value ] ] ........ 110memprint [:FuN ] addr....................... 110

Source File Display ................................. 111show source ....................................... 111list now .............................................. 111list [ next ].......................................... 111list previous ....................................... 111list around .......................................... 111list [ ’file’ ] num ................................ 111list +|-offset........................................ 111list [ ’file’ ] top,bot ............................ 111list [ func[tion ] funcname ................. 112disas ................................................... 112disas *addr1 [ ,*addr2 ] ..................... 112disas funcname .................................. 112

Automatic Display................................... 112screen [:F] expr.................................. 112screen ................................................. 112unscreen [#n] ..................................... 112screenoff [#n]..................................... 112

screenon [#n]......................................112show screen ........................................112

Symbols ...................................................113show function ["regex"] .....................113show variable ["regex"]......................113

Scripts ......................................................113alias cmd "cmd-str" ...........................113alias [cmd]..........................................113unalias [cmd]......................................113

Signals......................................................113signal sig action..................................113show signal [sig] ................................113

Miscellaneous Controls............................114param listsize num .............................114param prompt "str"............................114param printelements num...................114param prm ..........................................114

Files..........................................................114show exec...........................................114param execpath [path] ........................114param srcpath [path]...........................114show source........................................114show sources ......................................114

Fortran 95 Specific...................................115breakall mdl........................................115breakall func.......................................115show ffile............................................115show fopt............................................115

Communicating with fdb .........................115Functions ............................................115Variables ............................................115Values.................................................116Addresses ...........................................116Registers.............................................116Names.................................................116

Windows Debugging with WinFDB ...117How to Start and Terminate WinFDB .........117

Starting from the command prompt.........117Starting from the Windows desktop ........118Starting from the ED Developer ..............118Terminating the Debugger .......................118

Debugger Window .......................................119Debugger Window...................................119

Lahey/Fujitsu Fortran 95 User’s Guide iii

Contents

Debugger Menus ......................................... 120File Menu ................................................ 120Program Menu......................................... 120Debug Menu............................................ 121Mode Menu ............................................. 121Window Menu......................................... 122View Menu.............................................. 122Help Menu............................................... 122

Using the Debugger..................................... 122Starting the Program ............................... 123Setting and Deleting Breakpoints ........... 123

Setting a Breakpoint .......................... 123Releasing the Breakpoint ........................ 124Running and Stopping the Program ........ 125

Running the Program ........................ 125Stopping the Program........................ 125

Rerunning the Program ........................... 125Displaying Debug Information ............... 125

Displaying Variables ......................... 126Displaying Registers ............................... 126Displaying a Traceback........................... 127Displaying a Load Map........................... 127Entering FDB Commands....................... 128

Restrictions .................................................. 129Other Remarks............................................. 131

Library Manager ................................. 133Options ........................................................ 133Response Files ............................................. 135Creating and maintaining COFF libraries ... 135Extracting object files from libraries........... 136Creating import libraries ............................. 136

Make Utilities ...................................... 139Automake .................................................... 139

Overview................................................. 139Running AUTOMAKE ........................... 140The AUTOMAKE Configuration File Editor140The AUTOMAKE Configuration File .... 144Multi-Phase Compilation ........................ 150Automake Notes...................................... 151

NMAKE ...................................................... 152Overview................................................. 152Command line options ............................ 152

Description blocks ...................................153Substitution macros .................................154Suffixes....................................................155Suffix build rules .....................................155The TOOLS.INI file ................................156Example: Building a library ....................156Example: Building a program with module dependencies............................................157Example: Building multiple targets.........157

The Sampler Tool ...............................159Starting and Terminating the Sampler .........159

Starting the Sampler ................................159Starting from the Sampler icon..........160Starting from the Command prompt..160Terminating the Sampler ...................160

The Sampler Window ..................................160Sampler Menus ........................................161

File Menu...........................................161Sampler Menu....................................162View Menu ........................................162Window Menu ...................................163Help Menu .........................................163

Using the Sampler........................................163Collecting Tuning Information................164Displaying Tuning Information ...............164Displaying the Cost for Each Function....165Displaying the Cost Per Line...................165The Calling Relationship Diagram ..........166

The Coverage Tool .............................169Starting and Terminating the Coverage Tool169

Starting the Coverage Tool......................169Starting from the desktop icon...........169Starting from the Command prompt..169Terminating the Coverage Tool .........170

Coverage Window .......................................170Coverage Menus ..........................................170

File Menu.................................................171Coverage Menu........................................171View Menu ..............................................172Window Menu .........................................172Help Menu ...............................................173

Using the Coverage Tool .............................173Collecting Coverage Information ............173

iv Lahey/Fujitsu Fortran 95 User’s Guide

Contents

Storing & Merging Coverage Information .. 174Storing Coverage Information................. 174Merging Coverage Information............... 174Displaying Coverage Information ........... 175

Utility Programs..................................177DUMPBIN.EXE .......................................... 177

Invoking DUMPBIN ............................... 177DUMPBIN Options................................. 177

EDITBIN.EXE ............................................ 179Invoking EDITBIN ................................. 179EDITBIN Options ................................... 179

HDRSTRIP.F90........................................... 181LFSPLIT.EXE ............................................. 182MAKEDEF.EXE ......................................... 182SEQUNF.F90 .............................................. 182TRYBLK.F90 .............................................. 182UNFSEQ.F90 .............................................. 182WHERE.EXE .............................................. 183

Invoking WHERE ................................... 183

Programming Hints ............................185Efficiency Considerations............................ 185Side Effects.................................................. 185File Formats ................................................. 186

Formatted Sequential File Format........... 186Unformatted Sequential File Format....... 186Direct File Format ................................... 187Transparent File Format .......................... 187

Determine Load Image Size ........................ 187Link Time .................................................... 187Year 2000 compliance ................................. 188Limits of Operation. .................................... 189

Runtime Options.................................191Command Format ........................................ 191Command Shell Variable............................. 192Execution Return Values ............................. 193Standard Input and Output........................... 193Runtime Options.......................................... 193

Description of Options ............................ 194

Shell Variables for Input/Output ..................199

Lahey Technical Support ...................201Hours ............................................................201Technical Support Services..........................202

How Lahey Fixes Bugs............................202Contacting Lahey.....................................202Information You Provide .........................203Lahey Warranties.....................................204Return Procedure .....................................204

Lahey/Fujitsu Fortran 95 User’s Guide v

Contents

vi Lahey/Fujitsu Fortran 95 User’s Guide

1 Getting Started

Lahey/Fujitsu Fortran 95 (LF95) is a set of software tools for developing optimized 32-bit Fortran applications. LF95 is a complete implementation of the Fortran 95 standard. The toolset includes a compiler, editor, linker, debugger, profiler, coverage tool, librarian, make utility, video graphics and user interface library.

LF95 includes three manuals: the User’s Guide (this book), which describes how to use the tools; the Language Reference, which describes the Fortran 95 language; and the Winteracter Starter Kit Manual, which describes the Windows video graphics and user interface library.

System Requirements• An 80486DX, Pentium series or compatible processor• 24 MB of RAM (32 MB or more recommended)• 62 MB of available hard disk space for complete installation; 55 MB for typical

installation• Windows 9x, Windows ME, Windows NT 4.0, Windows 2000, or Windows XP.

Manual OrganizationThis book is organized into eleven chapters and three appendices.

• Chapter 1, Getting Started, identifies system requirements, describes the installation process, and takes you through the steps of building of your first program.

• Chapter 2, Developing with LF95, describes the development process and the driver program that controls compilation, linking, the generation of executable programs, libraries, and DLLs.

• Chapter 3, Mixed Language Programming, describes building statically linked and dynamically linked mixed language applications, and discusses interfacing Fortran procedures with procedures written with other languages.

Lahey/Fujitsu Fortran 95 User’s Guide 1

Chapter 1 Getting Started

• Chapter 4, Editing and Debugging with ED, describes program creation and debug-ging using the Windows-based programming environment.

• Chapter 5, Command-Line Debugging with FDB, describes the command-line debugger.

• Chapter 6, Windows Debugging with WinFDB, describes how to use the Windows-based debugging environment.

• Chapter 7, Library Manager, describes command-line operation of the librarian.• Chapter 8, Make Utilities, describes how to automate program creation. • Chapter 9, The Sampler Tool, describes how to profile your code to discover oppor-

tunities for execution speed optimization. • Chapter 10, The Coverage Tool, describes the coverage analysis tool which can be

used to determine if all portions of your code are being executed. • Chapter 11, Utility Programs, describes how to use the additional utility programs.• Appendix A, Programming Hints, offers suggestions about programming in Fortran

on the PC with LF95.• Appendix B, Runtime Options, describes options that can be added to your execut-

able’s command line to change program behavior.• Appendix C, Lahey Technical Support, describes the services available from Lahey

and what to do if you have trouble.

Notational ConventionsThe following conventions are used throughout this manual:

Code and keystrokes are indicated by courier font.

In syntax descriptions, [brackets] enclose optional items.

An ellipsis, '...', following an item indicates that more items of the same form may appear.

Italics indicate text to be replaced by the programmer.

non italic characters in syntax descriptions are to be entered exactly as they appear.

A vertical bar separating non italic characters enclosed in curly braces ‘{ opt1 | opt2 | opt3 }’ indicates a set of possible options, from which one is to be selected.

Product RegistrationTo all registered LF95 users, Lahey provides free, unlimited technical support via telephone (PRO version only), fax, postal mail, and e-mail. Procedures for using Lahey Support Ser-vices are documented in Appendix C, Lahey Technical Support.

2 Lahey/Fujitsu Fortran 95 User’s Guide

Installing Lahey/Fujitsu Fortran 95

To ensure that you receive technical support, product updates, newsletters, and new release announcements, please register during installation or at our website: http://www.lahey.com. If you move or transfer a Lahey product’s ownership, please let us know.

Installing Lahey/Fujitsu Fortran 95For Windows NT, Windows 2000, or Windows XP, the installation must be run while logged into the account which you will be using when running LF95. Administrator rights are required for installation.

The Lahey/Fujitsu Fortran 95 Setup Menu should automatically display when the CD is inserted in the drive. If the Setup Menu does not display, follow the instructions provided with the installation CD.

Select “Install Lahey/Fujitsu Fortran 95” from the Setup Menu. You’ll be prompted to enter or verify your LF95 serial number. The serial number is required to install LF95 and to receive technical support.

If you have the Standard or Professional versions, you will be given the choice for a 'Typical' or 'Custom' installation. If you have the 'Express' version, only the language system is installed.

The typical Standard version installation includes the following components:• LF95 Language System• Winteracter Starter Kit (WiSK)• f90SQL Lite• Fujitsu Coverage Tool• Fujitsu Sampler Tool• Lahey ED Developer• Online Documentation (PDF files)

The PRO edition will additionally install:• Fujitsu SSL2 (Scientific Subroutine Library)• Fujitsu Visual AnalyzerChoose 'Custom' to install the Fujitsu C-language Compiler component (PRO edition only), or to avoid installing any of the Typical components. 'Custom' will also give you more choices of which icons and system variables to install.

At the end of the installation, you will be given the choice to run Online Update. This will update your product to the most recent version of LF95 from Lahey’s website.

The appropriate LF95 directory names are appended to the PATH, LIB, and INCLUDE envi-ronment variables. The variables are appended, rather than prepended, in order to be less obtrusive to your current configuration. For the compiler, tools and utilities that are used as command-line programs, the "LF95 Console Prompt" is available on the Programs menu to start a console command-line with the environment variables optimally set. To to ensure cor-



rect operation of compilers, tools, and utilities in this product, we recommend either using the LF95 console prompt, or editing the aforementioned environment variables to put the LF95 directories ahead any others.

If you are using Windows 2000 or XP, your installation is complete. Otherwise, reboot your system (or log out and log in if using Windows NT) to insure that your system environment are properly set. You are now ready to build your first program.

Network InstallationNetwork Administrator: The network administrator role is to install the files on a network server drive for use by users on the client systems. Running the installation with the com-mand line arguments below will install the product files without creating icons (except the Internet folder to access Online Update) and without updating the system for use of the installed product components. It is required that you have purchased a site license from Lahey Computer Systems, Inc. or that you run monitoring software that limits the number of concurrent users of each tool in the distribution to the number of licenses purchased.

1. Enter this in the Start|Run option (do not run from the autoplay Setup Menu):

<d>:\Install32 netserver [ main:<n-m> ed4w:<n-e> ]

with these substitutions (the network pathname is the drive and directory specification):

<d> = the CD drive containing the Lahey/Fujitsu Fortran 95 CD

<n-m> = the network pathname for the compiler installation

<n-e> = the network pathname for the Lahey ED Developer installation

Note: the command line arguments surrounded by brackets are optional.

2. You will be prompted to accept the License Agreement, enter your registration informa-tion, enter/verify your installation directories, and to select which components you wish to install.

3. It is recommended that you make a batch procedure to distribute to your client users con-taining the command line shown below for the Network Client. Copy the file INSTALL32.EXE to a network-accessible drive for the clients to run the installation.

4. If the online documentation component is installed, then it is recommended that the Adobe Acrobat Reader install be made available for client users. This can be accomplished by copy-ing the "RPxxxenu.exe" installation program (where xxx is the version number) from the product CD to a network drive for the network users to run.

Network Client: Running the installation with the command line arguments below will install only those product files needed to be resident on the local system. The system files will be updated as necessary and icons will be updated as appropriate.


Maintenance Updates

1. You must have the network drive mapped as a local drive letter (e.g., starting with "N:"); do not specify a UNC style name (e.g., starting with "\\"). This requirement is for proper startup of Lahey ED Developer.

2. Enter this in Start|Run (do not run from the autoplay Setup Menu):

<n-i>\install32 netclient [ main:<n-m> ed4w:<n-e> local:<d-l> ]

with these substitutions (the network pathname is the drive and directory specification):

<n-i> = the network pathname where INSTALL32.EXE is located

<n-m> = the network pathname where the network admin installed the compiler

<n-e> = the network pathname where the network admin installed Lahey ED

<d-l> = the local pathname if the default of C:\Lahey is not desired.

Note: the command line arguments surrounded by brackets are optional.

3. If "main:" is not on the command line, the client user will be prompted to accept the License Agreement, enter the network location of the product, select desired shortcuts, and to choose whether or not to have the installation program update the system environment variables.

If "main:" is contained in the command line, the client user will not be prompted for any information, and the defaults will be used.

Maintenance UpdatesMaintenance updates are made available for free from Lahey's website. They comprise bug fixes or enhancements or both for this version of LF95. The update program applies "patches" to your files to bring them up-to-date. The maintenance update version shows as a letter after the version of your compiler. This is displayed in the first line of output when you run the compiler.

Any time you want to check the availability of a maintenance update for this version, click on “Online Update” in the Lahey/Fujitsu Fortran 95 Internet folder in your Programs menu, and a program will step you through the updating process. Online Update will first perform a quick check and tell you whether you are up-to-date or if an update is available. If you choose to install the update, the necessary patch files will be downloaded and applied. You need to be connected to the internet to perform the check and download the files.

To automatically check for updates at regular intervals at startup, press the Advanced button after starting Online Update and enter the interval (in days) in the Check Interval field. An LF95 Online Update icon will be added to your Windows Startup folder. At startup, Online



Update will start only if the specified check interval days have passed since the last time Online Update was run. Thereafter, to disable automatic checking, set the check interval to 0 (zero) days.

Another way to get the latest maintenance update for this version is by going to Lahey’s web page:

http://www.lahey.com

There you will find update programs you can download, as well as release notes and bug fix descriptions. Once you have downloaded an update program, you will no longer need an Internet connection. This method is preferred over Online Update by those who need to update LF95 on systems that are not connected to the Internet, or who want the ability to revert to a previous maintenance version.

In general, if you modify the contents of any of the files installed by this product (except within the Examples directory), that particular file will no longer be valid for updating, and the update installation program may abort with an error message.

Uninstalling LF95Do not delete the UNWISE.DAT file in your installation directory - it is critical to the unin-stallation program.

The uninstallation programs can be found in the Add/Remove Programs applet in the system Control Panel. Run the programs by selecting the Lahey/Fujitsu Fortran 95 and/or the Lahey ED Developer product title, press Add/Remove, and the program will start. The choice of Automatic, Manual, or Repair modes will be presented. Choose Automatic to remove all files which were created or overwritten by the original installation, and to remove directories (folders) which were created by the original installation and which are now empty. Any new files created after installation will not be removed. Choose Manual to select each separate filename to remove. See the next section for information about Repair mode.

Repairing LF95Do not delete the UNWISE.DAT file in your installation directory - it is critical to the repair program.

The repair programs can be found in the Add/Remove Programs applet in the system Control Panel. Run the programs by selecting the Lahey/Fujitsu Fortran 95 and/or the Lahey ED Developer product title, then press Add/Remove, and the program will start. The choice of Automatic, Manual, or Repair modes will be presented. Choose Repair to scan for missing files that were originally installed. The program will prompt for the installation program location, and will ask for verification of each file replacement. Do not choose to repair


Building Your First LF95 Program

(replace) any *.exe files, because many of these programs are registered with your serial number during installation. Rerun the installation program to replace damaged or missing executable files.

Building Your First LF95 ProgramBuilding and running a Fortran program with LF95 involves three basic steps:

1. Creating a source file using the Lahey ED development environment or a suitable non formatting text editor.

2. Generating an executable program using LF95. The LF95 driver automatically com-piles the source file(s) and links the resulting object file(s) with the runtime library and other libraries you specify.

3. Running the program.

The following paragraphs take you through steps two and three using the DEMO.F90 source file included with LF95. For the sake of illustration, we will use the command line interface to invoke LF95, even though it is a windows application.

Generating the Executable ProgramCompiling a source file into an object file and linking that object file with routines from the runtime library is accomplished using the LF95.EXE driver program.

Open a system command prompt by selecting Start|Programs|Lahey-Fujitsu Fortran 95 v5.7|Command Prompt. From the command prompt, build the demo program by changing to LF95’s EXAMPLES directory (where DEMO.F90 is installed), and entering

LF95 demo

This causes the compiler to read the source file DEMO.F90 (the extension.F90 is assumed by default) and compile it into the object file DEMO.OBJ. Once DEMO.OBJ is created, LF95 invokes the linker to combine necessary routines from the runtime library and produce the executable program, DEMO.EXE.

Running the ProgramTo run the program, type its name at the command prompt:

demo

and press Enter. The DEMO program begins and a screen similar to the following screen displays:



You've successfully built and run the Lahey demonstration program.

What’s Next?For a more complete description of the development process and instructions for using Lahey/Fujitsu Fortran 95, please turn to Chapter 2, Developing with LF95.

Before continuing, however, please read the files readme.txt and errata.txt. These contain important last-minute information and changes to the documentation.

Other Sources of InformationFiles

README.TXT last-minute informationREADME_PORT_LF90.TXT last-minute informationREADME_PORT_56.TXT last-minute informationREADME_F90SQL.TXT f90SQL-Lite informationREADME_SERVICE_ROUTINES.TXT POSIX and other service routinesFILELIST.TXT description of all files distributed with LF95ERRATA.TXT changes made after manuals went to pressIO_ERROR.TXT runtime I/O error messagesRTERRMSG.TXT other runtime error messagesSYSEDITS.TXT description of additions and changes made to

Lahey/Fujitsu LF95 Compiler --------------------------- installation test and demonstration program Copyright(c) 2001 Lahey Computer Systems, Inc. ----------------- Test/Action List: ----------------- 1 - factorials 2 - Fahrenheit to Celsius conversion 3 - Carmichael numbers 4 - Ramanujan's series 5 - Stirling numbers of the 2nd kind 6 - chi-square quantiles 7 - Pythagorean triplets 8 - date_and_time, and other system calls 0 - <stop this program> Please select an option by entering the associated number followed by <return>.


Other Sources of Information

Windows system directories by the LF95 install

ManualsLahey/Fujitsu Fortran 95 Language ReferenceLahey/Fujitsu Fortran 95 User’s Guide (this document)C Compiler User’s Guide (if selected at installation time)SSL2 User’s GuideSSL2 Extended Capabilities User’s GuideSSL2 Extended Capabilities User’s Guide IIVisual Analyzer User’s GuideWinteracter Starter Kit

Help FilesCoverage Tool Helpf90SQL-Lite HelpFujitsu C Help (if selected at installation time)Sampler Tool HelpVisual Analyzer HelpWinFDB debugger HelpWiSK Help

NewslettersThe Lahey Fortran Source newsletter

Lahey Web Pagehttp://www.lahey.com


2 Developing with LF95

This chapter describes how to use Lahey/Fujitsu Fortran 95. It presents an overview of the development process and describes how to build Fortran applications. LF95 controls com-pilation, the production of executable programs, static link libraries, and dynamic link libraries (DLLs).

The Development ProcessDeveloping applications with LF95 involves the following tools:

Editor. Use the Lahey ED development environment to create or modify Fortran source files. The driver can be run from within the editor. Compiler error messages are automatically keyed to lines of source code. ED also integrates debugging facilities for Windows applica-tions. See Chapter 4, Editing and Debugging with ED, for instructions on using Lahey ED.

Library Manager. Use the library manager to create, change, and list the contents of object libraries. See Chapter 7, Library Manager, for instructions on how to use the library manager.

Make Utility. Use the Automake or NMAKE utilities to automate program creation. Auto-make can be especially useful if your program consists of multiple files with modules. NMAKE can be used to build complex applications comprised of libraries, DLL’s and exe-cutables. See Chapter 8, Make Utilities, for instructions on how to use Automake and NMAKE.

Debuggers. For Windows console and GUI applications use FDB or WinFDB to debug your code (See Chapter 5, Command-Line Debugging with FDB and Chapter 6, Windows Debug-ging with WinFDB).

Driver. Use the driver (LF95.EXE) to control the creation of object files, libraries, execut-able programs, and DLLs. LF95.EXE is often referred to as a compiler, but it is actually a driver that invokes the appropriate compiler, linker, and other components used to create exe-cutables, libraries, and other products.


Chapter 2 Developing with LF95

The remainder of this chapter focuses on the driver and the processes it controls.

How the Driver WorksThe driver (LF95.EXE) controls the two main processes—compilation and linking—used to create an executable program. Supplemental processes, like creating static libraries, DLL’s, import libraries and processing Windows resources, are sometimes used depending on whether you are creating a DLL or a 32-bit Windows program. These processes are per-formed by the following programs under control of the driver:

Compiler. The compiler compiles source files into object files and creates files required for using Fortran 90 modules and files needed by the linker for creating DLLs.

Library Manager. LIB.EXE is the library manager. It can be invoked from the driver or from the command prompt to create or change static libraries.

Linker. LINK.EXE is the linker. The linker combines object files and libraries into a single executable program or dynamic link library. The linker also adds Windows resources, like icons and cursors, into Windows executables, and creates import libraries for use with LF95 dynamic link libraries (DLLs).

Resource Compiler. RC.EXE is the resource compiler. It converts Windows resource files (.RC files) to.RES files. .RES files can be sent to the linker, or can be converted by CVTRES.EXE into object files.

Running LF95By default, the LF95 driver program oversees compilation of any specified source files and will link them along with any specified object files and libraries into an executable program.

To run the driver, type LF95 followed by a list of one or more file names and optional com-mand-line options:

LF95 filenames [options]

The driver searches for the various tools (the compiler, library manager, linker, and resource compiler) first in the directory the driver is located and then, if not found, on the DOS path.

To display the LF95 version number and a summary of valid command-line options, type LF95 without any command-line options or filenames.

The command line options are discussed later in this chapter.


Filenames

FilenamesDepending on the extension(s) of the filename(s) specified, the driver will invoke the neces-sary tools. The extensions.F95,.F90,.FOR, and.F, for example, cause the compiler to be invoked. The extension .OBJ causes the linker to be invoked; the extension .RC causes the resource compiler to be invoked.

Filenames containing spaces must be enclosed in quotes.

Note: the extension .MOD is reserved for compiler-generated module files. Do not use this extension for your Fortran source files.

Source FilenamesOne or more source filenames may be specified, either by name or using the DOS wildcards * and ?. Filenames must be separated by a space.

ExampleLF95 *.f90

If the files ONE.F90, TWO.F90, and THREE.FOR were in the current directory, ONE.F90 and TWO.F90 would be compiled and linked together, and the executable file, ONE.EXE, would be created because the driver found ONE.F90 before TWO.F90 in the current directory. THREE.FOR would not be compiled because its extension does not match the extension spec-ified on the LF95 command line.

Source filenames are specified as a complete file name or can be given without an extension, in which case LF95 supplies the default extension .F90. In the absence of an option speci-fying otherwise:

.F90 and .F95 specifies interpretation as Fortran 95 free source form.

.FOR and .F specify interpretation as Fortran 95 fixed source form.

Source files for a given invocation of the driver should not mix free form and fixed form. If files with both the .FOR or .F and .F90 or .F95 appear on the same command line, then all are assumed to use the source form the driver assumes for the last file specified.

The -fix and -nfix compiler options can be used to control the assumed extension and override the interpretation specified by the extension. see “-[N]FIX” on page 26

Object FilenamesThe default name for an object file is the same as the source file name. By default, the object file is placed in the current directory.

Output FilenamesThe default name for the executable file or dynamic link library produced by the driver is based on the first source or object name encountered on the command line. By default, output files are placed in the same directory as the first file encountered. This may be overridden



by specifying the -OUT option with a new path and name (see “-OUT filename” on page 31). The default extension for executable files is .EXE. The default extension for static link librar-ies is .LIB. The default extension for dynamic link libraries is .dll.

OptionsThe driver recognizes one or more letters preceded by a hyphen (-) as a command-line option. You may not combine options after a hyphen: for example, -x and -y may not be entered as -xy.

Some options take arguments in the form of filenames, strings, letters, or numbers. You must enter a space between the option and its argument(s).

Example-i incdir

If an unknown option is detected, the entire text from the beginning of the unknown option to the beginning of the next option or end of the command line is passed to the linker.

Conflicts Between OptionsCommand line options are processed from left to right. If conflicting options are specified, the last one specified takes precedence. For example, if the command line contained LF95 foo -g -ng, the -ng option would be used.

Driver Configuration File (LF95.FIG)In addition to specifying options on the command line, you may specify a default set of options in the file LF95.FIG. When the driver is invoked, the options in LF95.FIG are pro-cessed before those on the command line. Command-line options override those in LF95.FIG. The driver searches for LF95.FIG first in the current directory and then, if not found, in the directory in which the driver is located.

Command FilesIf you have too many options and files to fit on the command line, you can place them in a command file. Enter LF95 command line arguments in a command file in exactly the same manner as on the command line. Command files may have as many lines as needed. Lines beginning with an initial # are comments.

To process a command file, preface the name of the file with the @ character. When LF95 encounters a filename that begins with @ on the command line, it opens the file and processes the commands in it.

ExampleLF95 @mycmds

In this example, LF95 reads its commands from the file mycmds.


Passing Information

Command files may be used both with other command-line options and other command files. Multiple command files are processed left to right in the order they are encountered.

Passing InformationThe LF95 driver uses temporary files for sending information between the driver and pro-cesses it controls. These files are automatically created using random names and are deleted when the process is complete.

Return Codes from the DriverWhen the LF95 driver receives a failure return code, it aborts the build process. The driver will return an error code depending on the success of the invoked tools. If a linker or resource compiler error occurs, LF95 exits with the exit code from the failing tool. Other return codes are listed below:

Note that there may be overlap between exit codes presented in Table 1 and exit codes passed through from a tool.

Creating a Console-Mode ApplicationLF95 creates Windows console-mode executables by default, so no options need be specified.

Example

LF95 MYPROG.F90

Table 1: Driver Return Codes

Code Condition

0 Successful compilation and link

1Compiler or tool failed to run or fatal compilation error occurred

2 Library Manager error

4 Driver error

5 Help requested



Creating a Windows GUI applicationTo create a Windows GUI application, either with a third-party package (such as Winter-acter, GINO, or RealWin) or by calling the Windows API’s directly, specify the -win option. To call the Windows API’s directly, you must also specify the -ml winapi option (see ”-ML { bc | bd | fc | lf90 | lf95 | msvb | msvc | winapi }” on page 29 and ”Calling the Windows API” on page 68 for more information). Note that console I/O is not permitted when using the -win option.

ExampleLF95 MYPROG.F90 -win

Creating a WiSK ApplicationLF95 comes bundled with a graphics library called WiSK (the Winteracter Starter Kit) which is derived from the full Winteracter library created by Interactive Software Services, Ltd. Winteracter is a Fortran 90 dedicated user-interface and graphics development tool that allows Fortran programmers to incorporate dialogs, menus, presentation graphics, and other windows features into their applications. Versions of WiSK and Winteracter exists for both Win32 and Linux platforms.

To create a 32-bit Windows program using procedures from the WiSK library, specify the -wisk option along with the program source and the name of a resource file created with ResEdit.

ExampleLF95 myprog.f90 myrc.rc -wisk

In this example, the source file MYPROG.F90 contains calls to the WiSK library and MYRC.RC contains resource definitions created by ResEdit. The following takes place:

1. MYPROG.F90 is compiled to create MYPROG.OBJ.2. MYRC.RC is compiled to create MYRC.RES.3. MYPROG.OBJ and MYRC.RESZ are automatically linked with the LF95 runtime

library and WISK.LIB,to create MYPROG.EXE, a 32-bit Windows executable.

Creating a 32-bit Windows DLLTo create a 32-bit Windows DLL, use the -dll option.

ExampleLF95 myprog.f90 -dll -win -ml msvc

In this example, the source file MYPROG.F90 contains procedures with DLL_EXPORT state-ments. The following takes place:

1. MYPROG.F90 is compiled to create MYPROG.OBJ.


Creating a static library

2. MYPROG.OBJ is automatically linked with the LF95 runtime library to create MYPROG.DLL and MYPROG.LIB, the corresponding import library. Calling conven-tions in this case are those expected by Microsoft Visual C/C++.

For more information on DLLs, see ”Dynamically linked applications” on page 44.

Creating a static libraryTo create a static library, specify the library name using the -out option.

ExampleLF95 mysub.f90 -out mylib.lib

LF95 recognizes that a library is requested because of the .lib extension for the output file. This causes LF95 to invoke the library manager rather than the linker. If the library specified with -out does not exist, it is created; if it already exists, it is updated.

OpenGL Graphics ProgramsOpenGL is a software interface for applications to generate interactive 2D and 3D computer graphics independent of operating system and hardware operations. It is essentially a 2D/3D graphics library which was originally developed by Silicon Graphics with the goal of creating an efficient, platform-independent interface for graphical applications (Note: OpenGL is a trademark of Silicon Graphics Inc.). It is available on many Win32 and Unix systems, and is strong on 3D visualization and animation.

f90gl is a public domain implementation of the official Fortran 90 bindings for OpenGL, con-sisting of a set of libraries and modules that define the function interfaces. The f90gl interface was developed by William F. Mitchell of the Mathematical and Computational Sci-ences Division, National Institute of Standards and Technology, Gaithersburg, in the USA. For information on f90gl, see the f90gl web page at:

http://math.nist.gov/f90gl

Until recently, the OpenGL LF9x applications could only be built as statically linked appli-cations targeted for Visual C. A much friendlier method is now available thanks to a porting effort implemented by Lawson B. Wakefield of Interactive Software Services Ltd. in the UK. (ISS are the developers of the INTERACTER & Winteracter GUI/graphics Fortran develop-ment tools). This implementation has made the OpenGL interface available within the framework of the WiSK and Winteracter libraries, and has been performed on a voluntary, non commercial basis. The Lahey LF95 f90gl interface therefore has the same non copy-righted status as the NIST original. A full set of examples is available under the WISK directory of the LF95 installation.

The OpenGL LibrariesTo use f90gl/OpenGL you will need three OpenGL DLL's installed in your Windows SYS-TEM or SYSTEM32 directory:



OPENGL32.DLLGLU32.DLLGLUT32.DLL

The first two of these libraries are a standard part of Windows NT4, 2000, XP, 95(OSR2), 98 and Me. Windows 95 release 1 users must upgrade to one of these releases. Many video card manufacturers now also provide accelerated OpenGL support as part of their video drivers. These drivers may replace the functionality of these two DLL's.

GLUT32.DLL is not part of the standard Windows distribution. GLUT32.DLL will be installed in the System or System32 (NT) directory by the installation program.

The f90gl Libraries & ModulesThe f90gl interface on the f90gl website is posted in source form only. For many users this is unsuitable since it requires a C compiler and a certain level of technical expertise in build-ing the interface. In the case of Lahey LF95, which uses the Microsoft linker, f90gl is best built using Microsoft Visual C.

This product eliminates the need for C compilers by providing pre-built f90gl modules and libraries suitable for use with Lahey LF95 5.7 and newer. The sources for f90gl are not included here since they are not required (as noted, they are available from the f90gl website).

Example ProgramsA subset of the f90gl examples are supplied in the LF95 EXAMPLES directory. A Run-Demos.bat file is included to build and run all of the examples.

Compilation and linking of f90gl programs simply requires that the LF95 LIB directory be specified in the compiler module path and that the names of the f90gl libraries are specified for linking. Specify -win to create a Windows program. See the RUNDEMOS.BAT file for command line examples. These are substantially simplified from the somewhat complex MF8N?O.BAT equivalents supplied with the f90gl distribution.

Example programs:

• Blender - two rotating objects, one red, one green, which fade in and out, plus some text.

• Fbitfont - some text

• Fscene - three 3D objects in red. The right mouse button brings up a menu. Redraw is really slow in outline mode on some machines.

• Logo - the f90gl logo. Rotate with the mouse while holding the left mouse button. Right mouse button brings up a menu. Middle mouse button selects a new value on the color bars (rgb sliders).

• Modview - contains a module for using the mouse and arrow keys to rotate, zoom, pan and scale. Initially the left button rotates (hold button down while moving mouse), middle button zoom, arrow keys pan, and right button brings up a menu.


Controlling Compilation

• Olympic - the olympic rings come flying into position. Restart the animation with the space bar; terminate with escape.

• Plotfunc - plots a function of two variables as contours, a surface mesh, or a solid surface. Uses the modview module. Right button brings up a menu.

• Scube - a rotating cube in front of a background. Right mouse button brings up a menu. There are also keyboard keys for the same functions as on the menu (look for keyboard in the source code).

• Sphere - a red sphere.

Sources of InformationGeneral inquiries and bug reports regarding f90gl should be sent to:

[email protected].

Lahey specific issues should be directed to [email protected].

OpenGL information can be found at http://www.opengl.org.

The ISS Winteracter user interface & graphics tools include a derivation of f90gl. LF95 includes the Winteracter Starter Kit (WiSK) which incorporates the same interface. Exam-ple programs are provided in the Examples\WiSK\OpenGL subfolder. Winteracter provides a richer set of user interface capabilities than the GLUT library used by the standard version of f90gl. See http://www.winteracter.com for more details.

Controlling CompilationDuring the compilation phase, the driver submits specified source files to the compiler for compilation and optimization. If the -c (compile only) option is specified, processing will stop after the compiler runs and modules are created (if necessary). See ”-[N]C” on page 21. Otherwise, processing continues with the appropriate action depending on what sort of output file is requested.

Errors in CompilationIf the compiler encounters errors or questionable code, you may receive any of the following types of diagnostic messages (a letter precedes each message, indicating its severity):

U:Unrecoverable error messages indicate it is not practical to continue compilation.S:Serious error messages indicate the compilation will continue, but no object file will be generated.W:Warning messages indicate probable programming errors that are not serious enough to prevent execution. Can be suppressed with the -nw or -swm option.



I:Informational messages suggest possible areas for improvement in your code and give details of optimizations performed by the compiler. These are normally sup-pressed, but can be seen by specifying the -info option (see ”-[N]INFO” on page 27).

If no unrecoverable or serious errors are detected by the compiler, the DOS ERRORLEVEL is set to zero (see ”Return Codes from the Driver” on page 15). Unrecoverable or serious errors detected by the compiler (improper syntax, for example) terminate the build process, and the DOS ERRORLEVEL is set to one. An object file is not created.

Compiler and Linker OptionsYou can control compilation and linking by using any of the following options. These options are not case sensitive. Some options apply only to the compilation phase, others to the linking phase, and still others (-g, -win, and -wisk) to both phases; this is indicated next to the name of the option. If compilation and linking are performed separately (i.e., in sepa-rate command lines), then options that apply to both phases must be included in each command line.

Compiling and linking can be broken into separate steps using the -c option. Unless the -c option is specified, the LF95 driver will attempt to link and create an executable after the compilation phase completes. Specifying -c anywhere in the command line will cause the link phase to be abandoned and all linker options to be ignored.

Some linker options require a number as an argument. By default, all numbers are assumed to be decimal numbers. A different radix can be specified by appending a radix specifier to the number. The following table lists the bases and their radix specifiers:

The underscore character (‘_’) can be used in numbers to make them more readable: 80000000h is the same as 8000_0000h.

Table 2: Radix Specifiers

Base Radix Specifier Example of 32 in base

2 B or b 10000b

8 Q or q 40q

10 none 32

16 H or h 20h


Compiler and Linker Options

-[N]AP Arithmetic PrecisionCompile only. Default: -nap

Specify -ap to guarantee the consistency of REAL and COMPLEX calculations, regardless of optimization level; user variables are not assigned to registers. Consider the following example:

Example X = S - T2 Y = X - U...3 Y = X - U

By default (-nap), during compilation of statement 2, the compiler recognizes the value X is already in a register and does not cause the value to be reloaded from memory. At statement 3, the value X may or may not already be in a register, and so the value may or may not be reloaded accordingly. Because the precision of the datum is greater in a register than in mem-ory, a difference in precision at statements 2 and 3 may occur.

Specify -ap to choose the memory reference for non INTEGER operands; that is, registers are reloaded. -ap must be specified when testing for the equality of randomly-generated values.

The default, -nap, allows the compiler to take advantage of the current values in registers, with possibly greater accuracy in low-order bits.

Specifying -ap will usually generate slower executables.

-BLOCK blocksizeDefault blocksizeCompile only. Default: 8192 bytes

Default to a specific blocksize for file I/O (See the OPEN Statement in the LF95 Language Reference). blocksize must be a decimal INTEGER constant. Specifying an optimal block-size can make an enormous improvement in the speed of your executable. The program TRYBLOCK.F90 in the SRC directory demonstrates how changing blocksize can affect exe-cution speed. Some experimentation with blocksize in your program is usually necessary to determine the optimal value.

-[N]CSuppress LinkingCompile only. Default: -nc

Specify -c to create object (.OBJ), and, if necessary, module (.MOD) files without creating an executable. This is especially useful in makefiles (see ”Make Utilities” on page 139), where it is not always desirable to perform the entire build process with one invocation of the driver.



-[N]CHK [([a][,e][,s][,u][,x])]CheckingCompile only. Default: -nchk

Specify -chk to generate a fatal runtime error message when substring and array subscripts are out of range, when non common variables are accessed before they are initialized, when array expression shapes do not match, and when procedure arguments do not match in type, attributes, size, or shape.

Note: Commas are optional, but are recommended for readability.

Specifying -chk with no arguments is equivalent to specifying -chk (a,e,s,u). Specify -chk with any combination of a, e, s, u and x to activate the specified diagnostic checking class.

Specification of the argument x must be used for compilation of all files of the program, or incorrect results may occur. Do not use with 3rd party compiled modules, objects, or librar-ies. Specifically, the x argument must be used to compile all USEd modules and to compile program units which set values within COMMONs. Specifying the argument x will force undefined variables checking (u), and will increase the level of checking performed by any other specified arguments.

If -chk (a) is specified in conjunction with -pca, the action of -chk (a) is overridden by the action of -pca. In this case, no error is generated when a dummy argument that is associated with a constant actual argument is assigned a new value in the subprogram.

Specifying -chk (u) checks for undefined variables by initializing them with a bit pattern. If that bit pattern is detected in a variable on the right side of an assignment then chances are that the variable was uninitialized. Unfortunately, you can get a false diagnostic if the vari-able holds a value that is the same as this bit pattern. This behavior can be turned off by not using the u argument to the -chk option. The values used with -chk (u) are:

One-byte integer: -117

Two-byte integer: -29813

Table 3: -chk Arguments

Diagnostic Checking Class Option Argument

Arguments a

Array Expression Shape e

Subscripts s

Undefined variables u

Increased (extra) x



Four-byte integer: -1953789045

Eight-byte integer: -8391460049216894069

Default real: -5.37508134e-32

Double precision real: -4.696323204354320d-253

Quadruple precision real: -9.0818487627532284154072898964213742q-4043

Default complex: (-5.37508134e-32,-5.37508134e-32)

Double precision complex: (-4.696323204354320d-253,-4.696323204354320d-253)

Quadruple precision complex: (-9.0818487627532284154072898964213742q-4043, -90818487627532284154072898964213742q-4043)

Character : Z’8B’

Specifying -chk adds to the size of a program and causes it to run more slowly, sometimes as much as an order of magnitude. It forces -trace and removes optimization by forcing -o0. Some of the arguments to the -chk option may severely impact program execution speed, depending on the source code. Eliminating unneeded options will improve speed.

ExampleLF95 myprog -chk (a,x)

instructs the compiler to activate increased runtime argument checking and increased unde-fined variables checking.

The -chk option will not check bounds (s) in the following conditions:

• The referenced expression has the POINTER attribute or is a structure one or more of whose structure components has the POINTER attribute.

• The referenced expression is an assumed-shape array.• The referenced expression is an array section with vector subscript.• The referenced variable is a dummy argument corresponding to an actual argument

that is an array section.• The referenced expression is in a masked array assignment.• The referenced expression is in a FORALL statement or construct.• The referenced expression has the PARAMETER attribute.• The parent string is a scalar constant.

Undefined variables (u) are not checked if:• Subscript checking (s) is also specified, and diagnostic message 0320-w, 0322-w, or

1562-w is issued.• The referenced expression has the POINTER attribute or is a structure variable one

of whose structure components has the POINTER attribute.• The referenced expression has the SAVE attribute.• The referenced expression is an assumed-shape array.



• The referenced expression is an array section with a vector subscript.• A pointer variable is referenced.• The referenced variable is a dummy argument corresponding to an actual argument

that is an array section.• The referenced expression is in a masked array assignment.• The referenced expression is in a FORALL statement or construct."

-[N]CHKGLOBALGlobal CheckingCompile only. Default: -nchkglobal

Specify -chkglobal to generate compiler error messages for inter-program-unit diagnos-tics, and to perform full compile-time and runtime checking.

The global checking will only be performed on the source which is compiled within one invo-cation of the compiler (the command line). For example, the checking will not occur on a USEd module which is not compiled at the same time as the source containing the USE state-ment, nor will the checking occur on object files or libraries specified on the command line.

Because specifying -chkglobal forces -chk (x), specification of -chkglobal must be used for compilation of all files of the program, or incorrect results may occur. Do not use with 3rd-party-compiled modules, objects, or libraries. See the description of -chk for more information.

Global checking diagnostics will not be published in the listing file. Specifying -chkglo-bal adds to the size of a program and causes it to run more slowly, sometimes as much as an order of magnitude. It forces -chk (a,e,s,u,x), -trace, and removes optimization by forcing -o0.

-[N]COCompiler OptionsCompile and link. Default: -co

Specify -co to display current settings of compiler options; specify -nco to suppress them.

-COMMENT commentInsert comment into executable fileLink only. Default: no comment

Specify -comment to insert a comment line into an executable file. If comment contains space or tab characters, it must be enclosed in double quotes.

-[N]CONCCSupport carriage control characters in console I/OCompile only. Default: -concc

Specify -nconcc to turn off Fortran carriage control processing for console I/O.



-[N]COVERCoverage InformationCompile and link. Default: -ncover

Specify -cover to generate information for use by the coverage tool (see Chapter 10, The Coverage Tool). This option is required to run the coverage tool if a separate link is performed.

-[N]DALDeallocate AllocatablesCompile only. Default: -dal

Specify -dal to deallocate allocated arrays that do not appear in DEALLOCATE or SAVE statements when a RETURN, STOP, or END statement is encountered in the program unit containing the allocatable array. Note that -ndal will suppress automatic deallocation for Fortran 95 files (automatic deallocation is standard behavior in Fortran 95).

-[N]DBLDoubleCompile only. Default: -ndbl

Specify -dbl to extend all single-precision REAL and single-precision COMPLEX vari-ables, arrays, constants, and functions to 64 bit double-precision. If you use -dbl, all source files (including modules) in a program should be compiled with -dbl. Specifying -dbl may or may not result in a somewhat slower executable.

-[N]DLLDynamic Link LibraryLink only. Default: -ndll

Specify -dll to create a 32-bit Windows dynamic link library (for more information, see ”Dynamically linked applications” on page 44).

-[N]F90SQLUse f90SQL LiteCompile and link. Default: -nf90sql

Specify -f90sql to create an application using f90SQL Lite.

-[N]F95Fortran 95 ConformanceCompile only. Default: -nf95

Specify -f95 to generate warnings when the compiler encounters non standard Fortran 95 code.

Note that -nf95 allows any intrinsic data type to be equivalenced to any other intrinsic type.



-FILE filenameFilenameCompile and link. Default: not present

Precede the name of a file with -file to ensure the driver will interpret filename as the name of a file and not an argument to an option.

ExampleOn the following command line, bill.f90 is correctly interpreted as a source file:

LF95 -checksum -file bill.f90

On this next command line, bill.f90 is not recognized as a source file. The driver passes the unrecognized option, -checksum, to the linker and assumes the following string, “bill.f90”, is an argument to the -checksum option.

LF95 -checksum bill.f90

On this last command line, -file is not necessary. The order of driver arguments allows unambiguous interpretation:

LF95 bill.f90 -checksum

-[N]FIXFixed Source FormCompile only. Default: -nfix for .f90 and .f95 files; -fix for .for and .f files

Specify -fix to instruct the compiler to interpret source files as Fortran 90 fixed source form regardless of the file extension. -nfix instructs the compiler to interpret source files as For-tran 90 free source form regardless of the file extension.

ExampleLF95 @bob.rsp bill.f90

If the command file BOB.RSP contains -fix, BILL.F90 will be interpreted as fixed source form even though it has the free source form extension .F90.

LF95 assumes a default file extension of .f90. Specifying -fix causes LF95 to assume a default file extension of .for.

All source files compiled at the same time must be fixed or free. LF95 doesn’t compile files (including INCLUDE files) that mix both fixed and free source form.

-[N]GDebugCompile and link. Default: -ng

Specify -g to instruct the compiler to generate an expanded symbol table and other informa-tion for the debugger. -g automatically overrides any optimization option and forces -o0, no optimizations, so your executable will run more slowly than if one of the higher optimi-



zation levels were used. -g is required to use the debugger. Supplemental debug information is stored in a file having the same name as the executable file with extension .ydg. If the fol-lowing error message appears during linking

fwdmerg:[error] Terminated abnormally. (signal 11)

It means that the .ydg file was not created (contact Technical Support if this happens).

This option is required to debug if a separate link is performed.

-I path1[;path2 ...]Include PathCompile only. Default: current directory

Instruct the compiler to search the specified path(s) for Fortran INCLUDE files after searching the current directory. Separate multiple search paths with a semicolon, not spaces. If a space appears as part of a pathname, the entire path must be enclosed in quotes.

ExampleLF95 demo -i ..\project2\includes;..\project3\includes

In this example, the compiler first searches the current directory, then searches ..\project2\includes and finally ..\project3\includes for INCLUDE files speci-fied in the source file DEMO.F90

-[N]INImplicit NoneCompile only. Default: -nin

Specifying -in is equivalent to including an IMPLICIT NONE statement in each program unit of your source file: no implicit typing is in effect over the source file.

When -nin is specified, standard implicit typing rules are in effect.

-[N]INFO Display Informational MessagesCompile only. Default: -ninfo

Specify -info to display informational messages at compile time. Informational messages include such things as the level of loop unrolling performed, variables declared but never used, divisions changed to multiplication by reciprocal, etc.

-[N]LI Lahey Intrinsic ProceduresCompile only. Default: -li

Specify -nli to avoid recognizing non standard Lahey intrinsic procedures.



-LIBPATH dir1[;dir2 ...]Library PathLink only. Default: current directory.

The -LIBPATH option allows specification of one or more directories to be searched for libraries. Note that all necessary library files must still be called out in the command line.

ExampleLF95 main.obj -libpath d:\mylibs mine.lib

-[N]LONGLong IntegersCompile only. Default: -nlong

Specify -long to extend all default INTEGER variables, arrays, constants, and functions to 64 bit INTEGER. If you use -long, all source files (including modules) in a program should be compiled with -long.

-[N]LST [(f=fval[,i=ival])]ListingCompile only. Default: -nlst

Specify -lst to generate a listing file that contains the source program, compiler options, date and time of compilation, and any compiler diagnostics. The compiler outputs one listing file for each compile session. By default, listing file names consist of the root of the first source file name plus the extension .lst.

You may optionally specify f for the listing file name, or i to list the contents of INCLUDE files.

fval specifies the listing file name to use instead of the default. If a file with this name already exists, it is overwritten. If the file can't be overwritten, the compiler aborts. If the user spec-ifies a listing file name and more than one source file (possibly using wild cards) then the driver diagnoses the error and aborts.

ival is one of the characters of the set [YyNn], where Y and y indicate that include files should be included in the listing and N and n indicate that they should not. By default, include files are not included in the listing.

ExampleLF95 myprog -lst (i=y)

creates the listing file myprog.lst, which lists primary and included source. Note that -xref overrides -lst.

See also“-[N]XREF [(f=fval[,i=ival])]”



-[NO]MAP filenameChange map file nameLink only. Default: create a map file with same name as output file

The -MAP option is used to specify a name for the linker map file. The linker map file is a text file describing the output load image. The map file contains the following information:

• names of the input object files,• a list of the segments comprising the program, and• a list of the public symbols in the program.

By default, the linker produces a map file each time a program is linked. The default name of the map file is the name of the output file, with its extension changed to .MAP. Any path information specifying a directory where the output file is to be placed also applies to the map file.

The -MAP option renames or relocates the map file. The option takes a single argument, which is the path and name of the map file to be produced. If no path information is specified in the map file name, then it is placed in the current directory.

The linker can be prevented from producing a map file with the -NOMAP option. The option takes no arguments. The -NOMAP option is useful to make the linker run faster, since no time is spent writing a map file. The option is also a good way to save disk space, because map files can be quite large.

ExamplesLF95 moe.obj larry.obj curly.obj -map stooges.nuk

LF95 hello.obj -nomap

-[N]MAXFATALS numberMaximum Number of Fatal ErrorsCompile only. Default: -maxfatals 50

Specify -maxfatals to limit the number of fatal errors LF95 will generate before aborting. If no argument is specified, the driver will abort with an error message.

If -nmaxfatals is specified, no argument is allowed.

-ML { bc | bd | fc | lf90 | lf95 | msvb | msvc | winapi }Mixed Language Compile and link. Default: -ml lf95

Specify the -ml option if your code calls or is called by code written in another language or if your code will call procedures in DLLs created by LF95. -ml affects name mangling for procedure names in DLL_IMPORT, DLL_EXPORT, and ML_EXTERNAL statements. See ”Mixed Language Programming” on page 43 for more information.



Use bc for Borland C++; bd for Borland Delphi; msvb for Microsoft Visual Basic; msvc for Microsoft Visual C++; fc for Fujitsu C; LF95 for LF95; LF90 for LF90; and winapi for accessing the Windows API directly.

-MLDEFAULT { bc | bd | fc | lf90 | lf95 | msvb | msvc | winapi }Mixed Language DefaultCompile only. Default: -mldefault lf95

Specify the -mldefault option to set the default target language name decoration/calling con-vention for all program units. Use the -ml option to alternatively affect name mangling only for procedure names in DLL_IMPORT, DLL_EXPORT, and ML_EXTERNAL statements.

Use bc for Borland C++; bd for Borland Delphi; msvb for Microsoft Visual Basic; msvc for Microsoft Visual C++; fc for Fujitsu C; LF95 for LF95; LF90 for LF90; and winapi for accessing the Windows API directly.

-MOD dir1[;dir2 ...]Module PathCompile only. Default: current directory

Specify -mod dir to instruct the compiler to search the specified directory for previously compiled LF95 module files (.MOD). If source code containing a module is being compiled, the module .MOD and .OBJ files will be placed in the first directory specified by dir.

When a program that uses a module is linked, the module's object file (or library name) must be provided on the command line. See ”Linking Fortran 95 Modules” on page 39 for more information and examples.

ExampleLF95 modprog mod.obj othermod.obj -mod ..\mods;..\othermods

In this example, the compiler first searches ..\mods and then searches ..\othermods. Any module and module object files produced from modprog.f90 are placed in ..\mods.

-NOLOGOLinker BannerLink only. Default: show linker logo

Suppress the LINK version and copyright message.

{ -O0 | -O1 }Optimization LevelCompile only. Default: -o1

Specify -o0 to perform no optimization. -o0 is automatically turned on when the -g option or the -chk option is specified. see “-[N]G” on page 26

Specify -o1 to perform optimization of object code.



-O filenameObject FilenameCompile only. Default: name of the source file with the extension .OBJ

Specify -o filename to override the default object file name. The compiler produces an object file with the specified name. If multiple source file names are specified explicitly or by wildcards, -o causes the driver to report a fatal error.

-OUT filenameOutput FilenameLink only. Default: the name of the first object or source file.

If -out is not specified, the output file is not automatically placed in the current directory. By default it is placed in the same directory as the first source or object file listed on the com-mand line.

This option takes a single argument, which is the path and name of the output file. If filename contains no path information, the output file is placed in the current directory.

If the file extension .EXE is specified, an executable file will be created. If no extension is specified with the -ndll option (default), the .exe extension is assumed.

If the file extension .dll is specified, a dynamic-link library will be created. If no extension is specified with the -dll option, the .dll extension is assumed.

If the file extension .LIB is specified, and the specified library file does not exist, it will be created. If the specified library already exists, it will be updated.

ExamplesLF95 hello.obj -out d:\LF95\hello.exeLF95 main.obj -out maintest

-[N]PAUSEPause After Program CompletionCompile only. Default: -npause

Specifying -pause will cause the executable program to wait for a keystroke from the user at program completion, before returning to the operating system. This option can be used to keep a console window from vanishing at program completion, allowing the user to view the final console output. If -npause is specified, the console window will vanish at program completion if the program is invoked from Windows Explorer or the Start menu, or if the console is generated by a Windows GUI application.

See also-WIN and -WINCONSOLE

-[N]PCAProtect Constant ArgumentsCompile only. Default: -npca



Specify -pca to prevent invoked subprograms from storing into constants. The -pca option will silently protect constant arguments and does not produce any warnings.

If -pca is specified in conjunction with -chk (a), the action of -chk (a) is overridden by the action of -pca. In this case, no error is generated when a dummy argument that is associated with a constant actual argument is assigned a new value in the subprogram.

Examplecall sub(5)print *, 5endsubroutine sub(i)i = i + 1end

This example would print 5 using -pca and 6 using -npca.

-[N]PREFETCH [{ 1 | 2 }]Generate prefetch optimizationsCompile only. Default: -nprefetch

Prefetch optimizations can improve performance on systems which support prefetch instruc-tions, such as Pentium III and Athlon systems.

The prefetch 1 option causes prefetch instructions to be generated for arrays in loops. The prefetch 2 option generates optimized prefetch instructions. Because Pentium 4 chips imple-ment prefetch in hardware, the use of -prefetch can adversely affect performance on those systems. Performance will be program dependent. Try each prefetch option (-nprefetch, -prefetch 1, or -prefetch 2) to determine which works best with your code. The -prefetch option will be ignored if -o0 or -g are used.

Please note: code generated with -prefetch is not compatible with processors made before the Pentium III or Athlon.

-[N]PRIVATEDefault Module AccessibilityCompile only. Default: -nprivate

Specify -private to change the default accessibility of module entities from PUBLIC to PRIVATE (see PUBLIC and PRIVATE statements in the Language Reference).

-[N]QUADQuadruple PrecisionCompile only. Default: -nquad

Specify -quad to extend all double-precision REAL and double-precision COMPLEX vari-ables, arrays, constants, and functions to 128 bit REAL and COMPLEX respectively. Specifying -quad forces -dbl, so using -quad causes the precision of all REAL variables to be doubled.



If you use -quad, all source files (including modules) in a program should be compiled with -quad. Specifying -quad will usually result in significantly slower executables. All excep-tions are trapped by default. This behavior can be overridden using the NDPEXC subroutine or the ERRSET service subroutine (see the file ReadMe_Service_Routines.txt).

-[N]SAVSAVE Local VariablesCompile only. Default: -nsav

Specify -sav to save local variables in between subprogram invocations. -nsav causes local variables to be stored on the stack, and their value is not retained in between subpro-gram invocations. -sav is equivalent to having a SAVE statement in each subprogram except that -sav does not apply to local variables in a recursive function whereas the SAVE statement does. Specifying -sav will cause your executable to run more slowly, especially if you have many procedures. Specifying -nsav may sometimes require more stack space than provided by default (see ”-STACK reserve[:commit]” on page 33).

-[N]SPLITCreate temporary files for each program unitCompile only. Default: -nsplit

Specifying -split will instruct the compiler to create and compile temporary source files for each program unit. An object file will be created with the same name as the filename con-taining the main program unit, and all other object files made from the temporary source files will be placed in a library given the name of the respective source filename. If linking is per-formed in a separate step, specify the main object and the library filename(s). See the file splitter utility ”LFSPLIT.EXE” on page 182 for an alternative way to divide the source code.

When debugging an executable created with -g option, you will be unable to set a break point by line number if the line is out of the current scope. (Use LFSPLIT to permanently split your file for better compatibility with the debugger.)

When using Automake to build your program, the library name(s) must be added to the link options.

The -split option is not compatible with the -ml and -mldefault options. The source filename(s) must have the .f90, .f95, .for, or .f extension. The error summary at the end of the compile will not be displayed.

If error 8694-U occurs, the compile will automatically be restarted with the -split option.

-STACK reserve[:commit]Stack SizeLink only. Default: -stack 1000000h

The -STACK option specifies the size of the stack area for a program. The option must be followed by a numeric constant that specifies the number of bytes to be allocated to the stack.



reserve is the maximum size of the stackcommit is the increment used when increasing the stack size during runtime

A space must appear between the option and reserve.

If a stack segment is already present in the program, then the -STACK option changes the size of the existing segment. The linker will only increase the size of the existing stack area. If an attempt is made to decrease the size of the stack area, the linker issues an error.

LF95 does not allocate local variables on the stack except in these cases:

• Procedures with RECURSIVE keyword• Procedures with the AUTOMATIC statement/attribute

The LF95 compiler does not have a compiler option to output the required stack size.

A program will not necessarily allocate the maximum amount of stack at the time it is loaded into memory. If it needs more stack during execution, it will dynamically increase the stack.

If your program exceeds the maximum amount of stack at runtime, increase the stack size with -STACK. Note that some recursive procedures and files with large arrays compiled with -nsav can use very large amounts of stack.

ExamplesLF95 hello.obj -stack 2000000

LF95 howdy.obj -stack 2000000:10000

-[N]STATICLIBStatic or Dynamic Linking of Fortran Runtime LibrariesLink only. Default: -staticlib

Specify -nstaticlib to dynamically link an executable or DLL with the Fortran runtime libraries in DLL form.

Specify -staticlib to statically link the Fortran runtime libraries with your executable or DLL.

-[N]STATICLINKStatic Link Compile only. Default: -nstaticlink

Specify -staticlink with -win and -ml to link statically with code produced by another supported language system. See ”Statically linked Fortran and C applications” on page 48 for more information.

-[N]STCHKStack Overflow CheckCompile only. Default: -stchk



Specify -nstchk to cause the compiler not to generate code for stack overflow checking. Though your program may execute faster, the stack is not protected from growing too large and corrupting data.

-[N]SWM msgno

Suppress Warning Message(s)

Compile only. Default: -nswm

To suppress a particular error message, specify its number after -swm.

Example

-swm 16,32

This example would suppress warning messages 16 and 32. To suppress all warnings, use -nw.

{ -T4 | -TP | -TPP }Target Processor

Compile only. Default: set on installation

Specify -t4 to generate code optimized for the Intel 80386 or 80486 processor.

Specify -tp to generate code optimized for the Intel Pentium or Pentium MMX processors, or their generic counterparts.

Specify -tpp to generate code optimized for the Intel Pentium Pro, Pentium II, Pentium III, or Celeron processors, or their generic counterparts.

Please note: code generated with -tpp is not compatible with processors made earlier than the Pentium Pro.

-[N]TRACELocation and Call Traceback for Runtime Errors

Compile and link. Default: -trace

The -trace option causes a call traceback with procedure names and line numbers to be gen-erated with runtime error messages. With -ntrace no line numbers are generated, and the Sampler tool cannot be used (the Sampler tool requires line number information -- see Chap-ter 9, The Sampler Tool).



-[N]TRAP [d][i][o][u]Trap NDP ExceptionsCompile only. Default: -ntrap

The -trap option specifies how each of four numeric data processor (NDP) exceptions will be handled at execution time of your program.

Specify -trap with any combination of d, i, o, and u to instruct the NDP chip to generate an interrupt when it detects the specified exception(s) and generate an error message. At least one argument must be specified when the -trap option is used.

Note that the zero divide exception for two and four byte integers is always handled by hard-ware, and is not affected by the trap option.

Note that trapping cannot be disabled when -quad is specified, except by using the NDPEXC subroutine or the ERRSET service subroutine (see the file ReadMe_Service_Routines.txt).

-VERSIONDisplay Version InformationDisables compile and link. Default: none

The -version option causes the compiler version, copyright and registration information to be printed. Any other options specified on the command line are ignored.

-[N]VSWVery Simple WindowsCompile and link. Default: -nvsw

The -vsw option creates a simple console-like Windows GUI application with a scrollable window.

-[N]W Compiler WarningsCompile only. Default: -w

Specify -nw to suppress compiler warning and informational messages.

Table 4: NDP Exceptions

NDP Exception Option Argument

Divide-by-Zero d

Invalid Operation i

Overflow o

Underflow u



-WARN, -FULLWARNLinker WarningsLink only. Default: no warnings

The linker detects conditions that can potentially cause run-time problems but are not neces-sarily errors. LF95 supports two warning levels: -warn, and -fullwarn.

-warn enables basic linker warning messages.

-fullwarn provides the maximum level of warning and informational messages.

-[N]WIDE Extend width of fixed source codeCompile only. Default: -nwide

Using the -wide option causes the compiler to accept fixed form source code out to column 255. The default is to accept code out to column 72

-WIN or -WINCONSOLEWindowsCompile and link. Default: -winconsole

Specifying -winconsole will create a console mode application. A Windows console will be created if the program is invoked from Windows Explorer, a menu selection, or a program icon, and it will disappear after program completion unless the -pause option is specified. If the program is invoked from the command line of an existing console, all console I/O will be performed within that console.

Specifying -win will create a Windows mode application. Under Windows 9x, console I/O is not permitted if the -win option was specified. Console I/O with -win is allowed if your program is running under a newer Windows operating system. If your program reads from or writes to standard output, a console will be created and will disappear upon program completion.

See also-[N]PAUSE

-[N]WISKWinteracter Starter KitCompile and link. Default: -nwisk

Specify -wisk to create an application using the Winteracter Starter Kit (WiSK, see the Winteracter Starter Kit Manual). Note that a resource file name must be given on the com-mand line whenever specifying -wisk. See the Winteracter Starter Kit manual for more information.



-[N]WOWarn ObsolescentCompile only. Default: -nwo

Specify -wo to generate warning messages when the compiler encounters obsolescent For-tran 95 features.

-[N]XREF [(f=fval[,i=ival])]Cross-Reference ListingCompile only. Default: -nxref

Specify -xref to generate cross-reference information. This information is shown in the list-ing file in addition to the information that the -lst option would provide. Note that -xref overrides -lst. By default, cross reference file names consist of the root of the source file name plus the extension .lst.

You may optionally specify f for the listing file name, or i to list the contents of INCLUDE files.

fval specifies the listing file name to use instead of the default. If a file with this name already exists, it is overwritten. If the file can't be overwritten, the compiler aborts. If the user spec-ifies a listing file name and more than one source file (possibly using wild cards) then the driver diagnoses the error and aborts.

ival is one of the characters of the set [YyNn], where Y and y indicate that include files should be included in the listing and N and n indicate that they should not. By default, include files are not included in the listing.

ExampleLF95 myprog -xref(i=y)

creates the cross reference file myprog.lst and outputs cross reference information for the source file.

See also-[N]LST

-[N]ZEROInclude Variables Initialized to ZeroCompile only. Default: -zero

Specifying -zero will cause all variables which have been explicitly initialized to zero to be given initialization values in the object file.

Specifying -nzero will cause explicit initializations to zero to not be given initialization val-ues in the object file, but to be initialized at load time. This will cause object files created with -nzero to potentially be much smaller.

Note that specifying the -CHK (u) option will diagnose undefined variables that are not explicitly initialized or assigned by your Fortran code, even when -zero is specified.


Linking

LinkingLinking an application should always be done under the control of the LF95 driver; it is not necessary to separately invoke LINK.EXE. Linking will occur automatically, as long as the -c option is not specified. Any combination of source, object, library, and resource files can be provided on the LF95 command line, and LF95 will first compile files using the Fortran or resource compiler, depending on the extension of the specified file, and then invoke the linker.

During the link phase, the driver submits object files, object file libraries, and compiled resource files to the linker. The linker reads individual object files and libraries, resolves ref-erences to external symbols, and writes out a single executable file or dynamic link library. The linker can also create a map file containing information about the segments and public symbols in the program.

Additional Linker OptionsIn addition to the link options described in the above section, Microsoft-specific link options which are not documented here may be used on the LF95 command line. These options should be specified with a hyphen (-), not a slash (/) and are sent to the linker unmodified. The linker is fully documented on Microsoft’s web site at:

http://msdn.microsoft.com

Linking Fortran 95 ModulesAn object file that is created when compiling a module is treated like any other object file. When linking a program that uses a module, the module’s object file must be provided to the linker along with the rest of the program. This can be done in one of several ways:

• If the module was already compiled, the object file can be provided along with the other filenames that comprise the program at the time the program is linked.

• If several modules are being used, their object files may be placed in a static library, and the library name can be supplied when linking.

• The module source can be compiled and linked at the same time as the other source files that make up the program. This can be done by specifying all the source that makes up the program on the LF95 command line without specifying the -c option. If this is done, the module source files should appear on the command line before any source files that use the module, and the executable name should be specified using the -out option.



Object File Processing RulesObject files are processed in the order in which they appear on the command line. If an object file has no path information, it is searched for first in the current directory, and then in any directories listed in the LIB environment variable.

Linking LibrariesNo special switch is needed to indicate that a library is to be linked, the driver is able to infer that the file is a library due to the .lib extension. A library should be specified by listing the library file name with the .lib extension on the command line in the same way that a source or object file is specified.

Libraries are searched in the order in which they appear on the LF95 command line. If mul-tiple libraries contain the same object, the first object encountered is linked, and any duplicate objects in subsequent libraries are ignored.

If a library file is specified without path information, the linker looks for it in the following order:

1. In the current working directory2. In any directories specified with the -LIBPATH option.3. In any directories specified in the LIB environment variable.

Recommended Option SettingsInspect the LF95.FIG file to determine current option settings.

For debugging, the following option settings will provide an increased level of diagnostic ability, both at compile time, and during execution:

-chk -g -stchk -trace -w -info

The -pca option may be additionally be used to check for corruption of constant arguments; if the results are correct with -pca but bad with -npca a constant argument has been corrupted.

For further analysis during development, consider specifying any of the following options:

-ap -chkglobal -co -cover -f95 -lst -wo -xref

(Note: Specifying -chkglobal or -chk (x) must be used for compilation of all files of the program, or incorrect results may occur.)

For production code, we recommend the following option settings:

-nap -nchk -nchkglobal -ncover -ndal -ng -o1 -npca -nsav -nstchk -ntrace


Recommended Option Settings

Use -t4, -tp, or -tpp depending on your preferred target processor. Note that use of -tpp will require that the program be run on a Pentium pro processor or later.

For additional optimization, experiment with the -nprefetch, -prefetch 1 or -prefetch 2 options and select the one which provides the best performance.


3 Mixed Language Programming

Mixed language programming is the process of melding code created by different program-ming languages into an executable program. There are two possible ways that this might be accomplished: by creating object files with different compilers that are linked into a single executable (static linking); or by creating a dynamic link library with one language, and call-ing procedures from the library using the other language (dynamic linking). Static linking mixes the different language parts into a single executable program which is self contained. Dynamic linking keeps the different language parts separate, and results in two separate enti-ties, a DLL created with one language, and an executable created with the other language.

Regardless of the method chosen to create a mixed language application, two basic problems need to be overcome by the programmer in order to be successful:

• The first problem involves how each language system names its procedures, and how names from one language system can be recognized by the other language system. Each procedure needs to know how the other is named, so that each can call and be called by the other within the execution environment. If the translation between the different naming conventions is not properly done, the programmer will not be able to link the different program parts together, because linker errors concerning unre-solved symbols will occur. Resolving the naming problem involves declaring any Fortran procedure names that are to be called from another language, declaring the other language procedure names that will be called in Fortran, and telling LF95 what calling convention is being used at compile time with the -ml compiler option. If a DLL is being used, a “translation” between the exported DLL procedures and how Fortran declares the procedures is provided in the form of an import library.

LF95 code that calls or is called by another language makes the name available by giving it the DLL_IMPORT, DLL_EXPORT or ML_EXTERNAL attribute. The DLL_IMPORT attribute is used when calling a procedure from a DLL. The DLL_EXPORT attribute is used to make a procedure name externally available when creating a Fortran DLL. The ML_EXTERNAL attribute is used to make a procedure from another language available to Fortran or making a Fortran procedure available


Chapter 3 Mixed Language Programming

to be called from another language when static linking. At compilation time, any procedure names having one of these attributes are ‘decorated’ to match the calling convention specified by the -ML option.

• Secondly, in order to be useful, the procedures need to be able to pass information back and forth in a way that both can understand and utilize. This involves the pass-ing of arguments to a subroutine or function, passing a function result between language systems, and how basic data types are interpreted by each language system. If arguments are not passed or interpreted correctly, the result can be unpredictable, and can range from nonsense answers to the program crashing with an “illegal oper-ation” message. The arguments passing problem is addressed for each supported language system, described in subsequent sections.

Dynamically linked applicationsA dynamically linked application consists of two parts: a separately created dynamic link library (DLL), and an executable program which references the DLL. A DLL is a collection of subprograms packaged together as an executable file, not a library file. Even though it is in the form of an executable, a DLL cannot run on its own. The functions and subroutines in a DLL are called from a .EXE file that contains a main program.

With LF95 you can create 32-bit DLLs for use with the language systems in the table below. Console I/O in the Fortran code is not recommended in Windows GUI applications, but just about everything else that is supported under Windows will work. Calls can be made from Fortran to Fortran, from Fortran to another language, and from another language to Fortran. Note that issuing a STOP statement from within a Fortran DLL will cause the entire program to terminate. If you are calling DLL procedures from a language system other than LF95, please refer to that language system’s DLL documentation for more information.

Supported language systemsLahey/Fujitsu Fortran 95 supports DLL calling conventions for the following languages systems:


Declaring calling conventions

Declaring calling conventionsIn order to reference a procedure across a DLL interface, the LF95 compiler must be informed of the procedure name to be exported, and given a calling convention for the exter-nal names in your DLL. The procedure names that will be externally available are defined with the DLL_EXPORT and DLL_IMPORT statements (see “DLL_EXPORT Statement” and “DLL_IMPORT Statement” in the LF95 Language Reference). Please note that procedure names appearing in a DLL_EXPORT or DLL_IMPORT statement are case sensitive (unlike the Fortran naming convention, which ignores case). DLL_EXPORT is used to define an exter-nally available DLL procedure, and DLL_IMPORT is used when referencing a DLL procedure. The calling convention is defined with the use of the -ML compiler option. You cannot mix -ml options in a single invocation of LF95. If you need to reference DLLs from multiple languages you can do so by putting the references in separate source files and com-piling them separately.

Table 5: Compiler Support for Lahey DLLs

Language System Version

Lahey/Fujitsu LF95 5.0 and later

Lahey LF90 2.01 and later

Borland C++ 5.0 and later

Borland Delphi 2.0 and later

Microsoft Visual C++ 2.0 and later

Microsoft Visual Basic 4.0 and later



LF95 can build DLLs callable from Microsoft Visual Basic, however, Microsoft Visual Basic does not build DLLs callable by LF95. Assembly procedures may be called from For-tran procedures, however the use of DOS interrupts is not supported.

Building Fortran DLLsWhen you create a Fortran DLL, you must indicate the procedures that you want to export from the DLL with the DLL_EXPORT attribute. The procedures may be subroutines or func-tions. When mixing languages, the function results must be of type default INTEGER, REAL, or LOGICAL. The case of the name as it appears in the DLL_EXPORT and DLL_IMPORT statements is preserved for external resolution except when the -ml lf90 option is used; within the Fortran code the case is ignored, i.e., Foo is the same as FOO. Note that the compiler allows you to build your DLL from multiple .OBJ files.

Example codefunction half(x)

integer, dll_export :: half ! name is case-sensitive

integer :: x

half = x/2

end

The code must be compiled using one of the options shown in Table 6, “-ML Options,” on page 46. When the -dll option specified, a DLL is created and a Microsoft-compatible import library is generated.

Example build commandlf95 -dll -win -ml msvc half.f90

Table 6: -ML Options

Option Compiler

-ml lf95 Lahey/Fujitsu Fortran 95

-ml lf90 Lahey Fortran 90

-ml bc Borland C++

-ml bd Borland Delphi

-ml msvc Microsoft Visual C++

-ml msvb Microsoft Visual Basic

-ml winapi Windows API functions invoked directly from Fortran


Building Import Libraries

The above command creates the files half.dll and half.lib which are compatible with Microsoft Visual C.

Building Import LibrariesA Microsoft-compatible import library is automatically generated whenever LF95 is used to create a DLL. When an LF95 program that calls a DLL is linked, a Microsoft-compatible import library must be provided. Usually, the vendor that supplies the DLL will also provide a Microsoft-compatible import library. Additional information on import libraries can be found in Chapter 7, Library Manager under the heading ”Creating import libraries” on page 136.

Building import libraries from object filesIf the user is building a non Fortran DLL on site for use with LF95, and a Microsoft-compat-ible import library is not created, an import library can be generated from the object files using LIB.EXE. Doing this entails making a definition file which contains the names of the exported procedures, and running LIB with the following command:

LIB /def:defile.def file1.obj file2.obj /out:implib.lib

Where:defile.def is the name of the definition file. Lahey provides a utility “MAKEDEF.EXE” to generate definition files given a DLL. Alternatively, the DUMPBIN utility can be used to list exported symbols from the DLL; then the definition file can be created by hand. Note that any export that appears in the definition file must be present in the object file, otherwise an unresolved reference will occur when the LIB command is executed. If this happens, it is usually sufficient to remove the unresolved reference from the definition file.

file1.obj and file2.obj are object files that were used to build the DLL.

implib.lib is the name of the import library to be produced.

Building import libraries when no object file is availableOccasionally, the situation occurs when only a DLL is available, without an import library or object files. If the user knows how to call the DLL procedure from Fortran, an import library can be generated using a stub program. A stub program is a skeleton that contains function or subroutine statements including any argument calling sequences, argument declarations, a DLL_EXPORT statement, and end statement, but no other source code - much like a proce-dure would appear inside an interface block. The stub file is compiled to create an LF95 object file, using an appropriate -ml option, and -c. Once the stub object file is created, the import library can be generated using the instructions in the preceding section: “Building import libraries from object files”. During execution of the LIB command, a warning con-cerning duplicate symbols may appear, if a non Microsoft convention is used, but it can be disregarded. Note that -ml lf95 should never be used to create import libraries from stubs. Code that calls the DLL should be compiled using the same -ml option that was used to com-pile the stub file. Note that the definition file that is used when creating the import library



should only contain procedure names that appear in the stub file, otherwise unresolved refer-ences will occur when the LIB command is executed. An example of creating import libraries using stubs appears in the EXAMPLES\MIX_LANG\BD directory.

Building non Microsoft import libraries for Fortran DLLsIf the user wishes to build an import library for a Fortran DLL that is called from a language that does not accept Microsoft-compatible import libraries, the 3rd party language will usu-ally provide a method of generating a compatible import library, such as Borland’s IMPLIB.EXE. In some cases, the 3rd party linker may provide commands that enable DLL references to be resolved. Consult the documentation provided with the 3rd party compiler and tools for instructions on resolving references to DLL procedures.

Examples of how to build Fortran callable DLLs from non Fortran languages, and how to generate Microsoft compatible import libraries from non Microsoft object files reside in directories under the EXAMPLES\MIX_LANG directory.

Delivering Applications with LF95 DLLsWhen you deliver applications built with LF95 DLLs, you must include the DLLs and asso-ciated import libraries you created. At runtime, all of the DLLs must be available on the path or in a directory that Windows checks for DLLs.

Statically linked Fortran and C applicationsStatically linked applications consist of a single executable file that contains all of the exe-cutable code and static data in the program. LF95 can link statically with code produced with Microsoft Visual C/C++ and Fujitsu C (FCC). LF95 is also static link compatible with object code created with Borland C/C++, but at this time it is not possible to reliably call C runtime procedures from Borland C.

Much of the following information is provided courtesy of Kenneth G. Hamilton --- 7-Oct-1998.

There are several reasons why you may wish to call a C function from your Fortran code. For example, you may have the C source code for a function that you need, but not want to take the time to recode it into Fortran. Or, you may wish to take advantage of some feature of C, such as unsigned integers, that is not available in Fortran. Additionally, many current oper-ating systems, including Microsoft Windows 95, 98, and NT, are written in C and the authors have not seen fit to document the interface to the system services in any other language.

You should, however, keep in mind that as a consequence of the extensive use of pointer arithmetic, C code ultimately cannot be optimized as well as Fortran. Most examples of fast, efficient, C code are the result of a great deal of programmer labor, just as is the case in assembly language coding.


Calling Conventions

Building statically linked applications

The information on building a statically linked program is the same as for dynamic linking (described above) with the following exceptions:

• Specify the -staticlink and -ml options on the LF95 command line (do not spec-ify -dll).

• Use ML_EXTERNAL instead of DLL_IMPORT or DLL_EXPORT in your Fortran source match the calling conventions of Visual C++ at compile time. If using Fujitsu C, calling conventions can be matched by following the instructions in the section ”Calling Conventions” on page 49.

• You must have a Fortran main program.

• Import libraries are not included on the LF95 command line (import libraries are spe-cific to DLLs).

• Fortran common blocks are aligned on one-byte boundaries. To align your C struc-tures along one-byte boundaries, use the /Zp1 option or the pack pragma with Microsoft Visual C++. Use the -a- option or the option -a- pragma with Borland C++. Note that use of these options should be limited to files or sections of code that require one-byte alignment; one-byte alignment can cause slower access to C struc-ture members.

There are several examples in the following sections. The source code, to enable you to expe-rience mixed-language calling, are in subdirectories examples\mix_lang\fcc\ex1, ex2, ex3, etc., below your main LF95 directory. Each one is accompanied by a file called GEN.BAT, that will compile and link the sample code. There are additional examples spe-cific to compiler type in the examples\mix_lang\msvc and examples\mix_lang\bc directories.

Calling ConventionsWhen it compiles Fortran source and emits object code, LF95 converts the names of all entry points and external references into all lower case letters, and attaches an underscore (_) sym-bol to both the front and back of each such name. FCC does not change the case of names, but it does add a leading underscore to each one.

Therefore, if a Fortran program calls a subroutine named "CLOUD", LF95 will generate a requirement for an external symbol called "_cloud_". If the subroutine is written in C, and compiled by FCC, then the entry point name must be "cloud_". (Note the absence of a lead-ing underscore, which will be added by FCC.)



Argument PassingTraditionally, Fortran compilers arrange for arguments to subroutines to be passed by refer-ence. This means that the address is passed (pushed on the stack, in the case of PCs) and so the called routine has full access to the variable in the caller, and can read or write to that location.

C compilers, on the other hand, pass simple (i.e., scalar) variables by value, meaning that the current value of that variable is pushed, rather than its address. The function that is called can thus read, but cannot change, the variable in the caller. More complicated objects, such as arrays and structures, are passed by reference by C compilers. (Confusion over which symbols represent values, and which addresses, is a common source of bugs in C programs, and so you should check your useage carefully.)

Trying to connect a Fortran caller to a C callee thus requires that one bridge these two con-ventions. It is possible to do this either by modifying the Fortran part or the C portion of the calling interface. Since LF95 is a Fortran package, in the examples that follow we will leave the Fortran form alone and modify the C side. This essentially means that C functions should be set up so as to expect that all visible arguments are being passed by reference, or "as point-ers" in the C lingo.

Passing Arrays in C or C++Because C processes arrays as an array of arrays and Fortran processes arrays as multi-dimensional arrays, there are some special considerations in processing a Fortran array. Excluding a single-dimension array (which is stored the same in C as in Fortran), you will need to reverse the indices when accessing a Fortran array in C. The reason for this is that in C, the right-most index varies most quickly and in Fortran the left-most index varies most quickly (multi-dimensional). In an array of arrays, the columns are stored sequentially: row 1-column 1 is followed by row 1-column 2, etc. In a multi-dimensional array, the rows are stored sequentially: row 1-column 1 is followed by row 2-column 1, etc.

Also note that all C arrays start at 0. We do not recommend that you use a lower dimension bound other than zero (0) as your C code will have to modify the indices based on the value used. We strongly recommend that you do not use negative lower and upper dimension bounds!

If the subscript ranges are not known at compile time, they can be passed at runtime, but you will have to provide the code to scale the indices to access the proper members of the array.

Some sample code may help explain the array differences. Your Fortran code would look like:

subroutine test(real_array)real :: real_array(0:4,0:5,0:6,0:7,0:8,0:9,0:10)integer :: i,j,k,l,m,n,odo o = 0, 10 do n = 0, 9 do m = 0, 8


Variable Type Correspondence

do l = 0, 7

do k = 0, 6

do j = 0, 5

do i = 0, 4

real_array(i,j,k,l,m,n,o) = 12.00

end do

end do

end do

end do

end do

end do

end do

end subroutine test

The equivalent C code would look like:

void test(float real_array[10][9][8][7][6][5][4])

int i,j,k,l,m,n,o;

/*

** this is what the subscripts would look like on the C side

*/

for(o = 0; o < 11; o++)

for(n = 0; n < 10; n++)

for(m = 0; m < 9; m++)

for(l = 0; l < 8; l++)

for(k = 0; k < 7; k++)

for(j = 0; j < 6; j++)

for(i = 0; i < 5; i++)

real_array[o][n][m][l][k][j][i] = 12.000;

return;

}

On the Fortran side of the call, the array argument must not be dimensioned as an assumed-shape array. You should use explicit shape, assumed size, or automatic arrays.

Variable Type CorrespondenceWhen passing arguments to a subprogram, it is necessary that they match the list of formal parameters on the entry point. The following table shows what various Fortran variable types correspond to in C.



The C language allows unsigned integers of various lengths. There is no direct analog of this in Fortran, however the unsigned integers that can be returned from C can be stored and slightly manipulated in Fortran. Fortran cannot perform arithmetic on unsigned integers, however this is often unnecessary: one of the most common uses for unsigned integers is as handles for files, windows, and other objects.

Handles are received, copied, and passed into other routines, but are never subjected to com-putation. It is therefore possible to treat a handle as simply an INTEGER of the appropriate length and there will be no problem. If it is necessary to display the value of a handle it can be done in hexadecimal (Z) format, with no loss of information.

Example 1 --- A Simple SubroutineFirst, let us look at the simplest example of a Fortran program calling a C subroutine. The following main program defines two integers, I and J, and then calls SUB to add them and return the sum.

Table 7: Variable Type Equivalents

Fortran Type Kind No. C Type

INTEGER 1 char

INTEGER 2 int

INTEGER 4 long

REAL 4 float

REAL 8 double

COMPLEX 4 struct{float xr, xi;}

COMPLEX 8 struct{double xr, xi;}

LOGICAL 1 char

LOGICAL 4 long

CHARACTER 1 (none)



PROGRAM MAIN integer :: i,j,k i = 12 j = 43 k = 0 print *, 'Before: i,j,k=',i,j,k call sub(i,j,k) print *, 'After: i,j,k=',i,j,k stop end

This is the subroutine that performs the addition.

void sub_(i,j,k)int *i, *j, *k;{ *k = *i + *j; return;}

In C, a subroutine is a function of type "void." As we noted earlier, the name of the subrou-tine must be in lower case letters, with a trailing underscore. Since Fortran normally passes arguments by reference, the C subroutine must receive them as pointers (hence the "*" in front of the variable names). The type INTEGER variables in Fortran are treated as type "int" in C.

Example 2 --- Passing Real ArgumentsThe situation is the same when floaing point arguments are passed. In this example, three default REAL(KIND=4) arguments are sent to a C subroutine, where they are manipulated.

PROGRAM FLTMAIN x = 2.17 y = 5.6 z = 0.0 print *,' x,y,z=',x,y,z call cmult(x,y,z) print *,' x,y,z=',x,y,z stop end

This is the C subroutine, where the REAL(KIND=4) variables are received as pointers to variables of type "float." If the arguments were REAL(KIND=8), then the C side would expect them as type "double."

void cmult_(x,y,z)float *x, *y, *z;{ *z = *x * *y + 2.0; return;}



Example 3 --- Passing CHARACTER ArgumentsPassing type CHARACTER variables poses a higher level of complexity. Consider the fol-lowing main program, which assigns a literal string to A, and then calls CHRCOPY to duplicate A into B.

PROGRAM CHRMAIN character*20 a, b a = 'This is a message' b = ' ' print *, 'a=',a print *, 'b=',b call chrcopy(a,b) print *, 'a=',a print *, 'b=',b stop end

When LF95 passes type CHARACTER arguments to a subroutine, it actually sends both the starting address of the string, plus the length (which is passed by value). The lengths of any CHARACTER arguments are treated as hidden arguments to the right of the normal argu-ment list.

Thus, in the following C subroutine, the argument list consists of four items, even thought we could see only two in the Fortran CALL statement. The first two arguments are the character strings, passed by reference so that they appear here as pointers to variables of type "char." (Type "char" in C is not a true string variable, but is rather a one-byte integer.)

The third and fourth arguments are the lengths of A and B, passed by value. We can tell that they are being passed by value here because they are not prefixed by asterisks, but just appear as plain variables.

#include <string.h>void chrcopy_(a,b,na,nb)char *a, *b;int na, nb;{ int nmin; nmin = na > nb ? nb : na; strncpy(b,a,nmin); return;}

The subroutine first compares the lengths of the two CHARACTER variables, and then selects the minimum (in case they are different). That becomes the number of characters to copy from A to B, and the C library routine "strncpy" is used.

Example 4 --- Passing ASCIIZ ArgumentsIn early Fortran compilers, character strings were stored as arrays of numeric storage loca-tions, packed several characters to each word and then terminated by a word or partial word of zero. Because different types of computer have different word lengths, this "Hollerith"



scheme often led to seriously nontransportable code. Some computers stored four characters per word, while others stored five, six, eight, or ten characters per word and so many routines that performed input or output required drastic reworking when moved from one brand of computer to another.

When the Basic language was released in the 1970s, it introduced the notion of a special "string" data type that was independent of the hardware design. This was such a good idea that it was copied into the 1977 Fortran standard as CHARACTER variables.

Unfortunately, at the same time that Fortran was copying from Basic, C was copying from Fortran and so currently C compilers still expect character strings to be stored as an array of numeric storage locations (usually bytes), terminated by a null. In some cases, you may find it preferable to pass CHARACTER variables to C by appending a null, so that it looks like the legacy method expected by the C language. In order to do this, you would change

CALL CSUB(...,ASTR,...)

into

CALL CSUB(...,ASTR//CHAR(0),...)

where ASTR is a CHARACTER variable. In this case, however, the Fortran compiler will make a copy of ASTR with the null attached, and pass that. This means that the subroutine will not be able to modify the original string since ASTR//CHAR(0) is an expression rather than a variable, but that may well be desireable.

If you want to allow the subroutine to modify the original string, then you should add the null into the CHARACTER variable, as shown in the following example.

PROGRAM CHRMAIN

character*20 a, b

a = 'Original text'//char(0)

b = ' '

print *, 'a=',a

print *, 'b=',b

call chrcaps(a,b)

print *, 'a=',a

print *, 'b=',b

stop

end

Here is a C subroutine that returns B as a capitalized version of A, as required by the main program.



void chrcaps_(a,b,na,nb)

char *a, *b;

int na, nb;

{

char *i, *j;

for (i = a, j = b; *i != 0; i++, j++) {

*j = *i;

if (*j >= 97 && *j <= 122) *j -= 32;

}

return;

}

In this case, the copying operation is halted by the appearance of a null (the "*i != 0" clause in the "for" statement). Local pointer variables *i and *j are used instead of the ones that were supplied by the caller.

Example 5 --- Accessing COMMON BlocksWhen LF95 processes COMMON blocks, it modifies them in the same way as it does entry points. That is to say that a block named /SAND/ will invisibly become a global object named "_sand_" and this alteration must be dealt with when performing interlanguage call-ing. The secret name of blank COMMON is "__BLNK__", with two underscores in front and behind.

Here is an example of a Fortran main program that supplies values to some variables that are in COMMON blocks, one blank and one named.

PROGRAM CMN_MAIN

integer :: i

real :: x,y,z

common /zulu/ x, y

common z

i = 12

x = 4.5

y = 0.0

z = 8.1

print *, 'Before: i,x,y,z=',i,x,y,z

call ccmn(i)

print *, 'After: i,x,y,z=',i,x,y,z

stop

end

That program calls the following C subroutine:



extern struct{ float x, y;} zulu_;

extern struct{ float z;} _BLNK__;

void ccmn_(i)int *i;{ zulu_.y = zulu_.x + (float)(*i); _BLNK__.z += zulu_.x; return;}

In order to access the COMMON blocks from C, we must define a pair of structures, and declare them outside of the function body so that they acquire the global attribute and can connect to the COMMON blocks that the Fortran compiler is going to set up.

Since C prepends an underscore to the global names, the named common /ZULU/, which is called "_zulu_" in the object modules, must be called "zulu_" (no leading underscore) in the C code. Likewise, the blank COMMON, called "__BLNK__" in the object code, is called "_BLNK__" (only one leading underscore) in C.

Example 6 --- FunctionsCalling a function that is written in C, one that returns a value (as opposed to a subroutine), is fairly simple as long as you make sure that the type of the function in C matches what For-tran expects to receive.

Here is an example of a Fortran main program that calls several C functions, each of a differ-ent type. The argument lists are the same for all the functions: two default integers, but the return value differs.

PROGRAM MAIN integer :: i,j integer(kind=1) :: k1, i1add integer(kind=2) :: k2, i2add integer(kind=4) :: k4, i4add real(kind=4) :: r4, r4add real(kind=4) :: r8, r8add external :: i1add, i2add, i4add, r4add, r8add! i = 12 j = 43 k1 = 0; k2 = 0; k4 = 0 print *, 'Before: i,j=',i,j



k1 = i1add(i,j) k2 = i2add(i,j) k4 = i4add(i,j) print *, 'After: k1,k2,k4=',k1,k2,k4 r4 = r4add(i,j) r8 = r8add(i,j) print *, 'r4,r8=',r4,r8! stop end

These are the C functions called by the Fortran main. Note that the type of variable for a function to return is specified in the opening statement, in place of the "void" that was used in the earlier subroutines.

char i1add_(i,j)int *i, *j;{ char k; k = *i + *j; return(k);}

short i2add_(i,j)int *i, *j;{ short k; k = *i - *j; return(k);}

long i4add_(i,j)int *i, *j;{ long k; k = *i * *j; return(k);}

float r4add_(i,j)int *i, *j;{ float r; r = (float)(*i) + (float)(*j); return(r);}


Fortran Calling Fortran DLLs

double r8add_(i,j)

int *i, *j;

{

double d;

d = (double)(*i) / (double)(*j);

return(d);

}

Fortran Calling Fortran DLLsEven though the same language system is used to create both the DLL and the executable, the mixed language rules must be observed. Create the Fortran DLL as described in ”Build-ing Fortran DLLs” on page 46, building with the -ml lf95 compile option:

lf95 source.f90 -win -dll -ml lf95

LF95 builds the DLL source.dll. It also generates a source.lib file containing defini-tions needed to link to this DLL.

Next build the Fortran Main with:

lf95 main.f90 -win -ml lf95 source.lib

To run the program, the DLL must be in the same directory as the executable, or in a directory on the path.

Fortran and C applications

Fortran calling C DLLsWhen you create a Fortran procedure that references a C procedure you declare the C proce-dure name with the DLL_IMPORT attribute in your Fortran code. The procedure may be a subroutine or function. C functions may only return the Fortran equivalent of default INTE-GER, REAL, or LOGICAL results.

Example code:program main

implicit none

real, dll_import :: My_Dll_Routine ! case-sensitive

real :: x

x = My_Dll_Routine()

write (*,*) x

end program main



Before building the Fortran main program with LF95, you must have a DLL and import library available. Refer to your C manual for specifics on creating a DLL. If the C compiler does not create a compatible import library (.LIB file) for the DLL, proceed as described above, ”Building Import Libraries” on page 47.

If the DLL was created with Microsoft Visual C++, use the -ml msvc option:

LF95 source.f90 -win -ml msvc dll_src.lib

If the DLL was created with Borland C++, use the -ml bc option:

LF95 source.f90 -win -ml bc dll_src.lib

Where dll_src.lib is the name of the Microsoft compatible import library.

There are examples of calling C DLLs in the directories below LF95’s EXAMPLES/MIX_LANG directory.

C Calling Fortran DLLsCreate the Fortran DLL as described in ”Building Fortran DLLs” on page 46, building with the -ml compile option that matches your C compiler.

To compile your Fortran source for use with Microsoft Visual C++, issue the command:

LF95 source.f90 -win -ml msvc -dll

This command will cause a DLL called source.dll to be created, as well as an import library called source.lib.

To compile your Fortran source for use with Borland C++, issue the command:

LF95 source.f90 -win -ml bc -dll

The user will need to run Borland’s IMPLIB.EXE to build the import library compatible with the Borland linker. IMPLIB is distributed with the Borland compiler, and is not a part of LF95.

Once you’ve created the DLL and generated the import library, use the C language system to link the associated import library (source.lib in the above cases) with your C object code, and be sure the DLL is available on your system path.

Referencing DLL ProceduresFortran functions are called from C as functions returning a value.

For example, this Fortran function:


Passing Data

function dll1(a, a1, i, i1, l, l1) integer, dll_export :: DLL1 real a, a1(10) integer i, i1(10) logical l, l1(10) ...end function

uses this C prototype:

long foo(long int *i, long int *j);

To reference the above function from your C code, declare it with _stdcall:

long _stdcall foo(long int *i, long int *j);

In C++, use:

extern "C" {long _stdcall foo(long int *i, long int *j); };

For a short example, see LF95’s EXAMPLES\MIX_LANG\MSVC directory (for Microsoft Visual C++) or LF95’s EXAMPLES\MIX_LANG\BC directory (for Borland C++).

Passing DataThe only ways to pass data to or from a DLL are as arguments, function results, or in files. LF95 does not support the sharing of data (as with a COMMON block) across the boundaries of a DLL. Arguments may be passed by reference (the default) or by value using either the CARG or VAL function. See ”Argument Passing” on page 50 for more information.

Microsoft Visual Basic Information

Visual Basic calling FortranTo create a DLL that will work with Microsoft Visual Basic, take Fortran source (without a main program) and indicate the procedures that you want available in the DLL with the DLL_EXPORT statement, then invoke the LF95 driver like this:

LF95 source.f90 -win -dll -ml msvb

Running the Visual Basic Demo1. Compile the VBDEMO.F90 file, located in LF95’s MIX_LANG\MSVB directory, using

the -dll -win -ml msvb options.

2. Ensure that the resulting VBDEMO.DLL resides in a directory that is on your path. Failure to do this will generally result in an “Error loading DLL” message from the operating system.



3. Start Visual Basic and open the VBDEMO.VBP project in LF95’s EXAMPLES\MIX_LANG\MSVB directory.

4. Run the demo (F5).

Declaring your Procedure in Visual BasicIn your BASIC code, a procedure’s declaration will be like one of the following examples:

Private Declare Function my_func Lib "my_dll" (ByRef my_arg As

Long) As Long

Private Declare Sub my_sub Lib "my_dll" (ByRef my_arg As Long)

(see the relevant section below if an item on the argument list is either an array or is character datatype). Note that in the example above, “my_dll” must specify a complete path in order to operate within the Visual Basic Environment.

Passing Character Data in Visual BasicCharacter arguments are passed as strings with the length of each string appended at the end of the argument list.

Character (string) arguments and hidden length arguments must be passed by value, i.e., declare the procedure’s arguments (actual and hidden) with the ByVal keyword. Refer to the example VBDEMO program. The following restrictions apply:

• Character arguments should be declared as CHARACTER(LEN=*).

• Fortran functions returning character data to Visual Basic are not supported.

Passing Arrays in Visual BasicWhen passing an array from Microsoft Visual Basic you will need to declare the argument as a scalar value in the Basic declaration, and pass the first element of the array as the actual argument. Declare the array dummy argument normally in the Fortran procedure. Note that the default lower bound for arrays in Visual Basic is 0, so you may find it helpful to explicitly declare your Fortran arrays with a lower bound of 0 for each dimension, or explicitly declare your Basic arrays to have a lower bound of 1 (this can be done at the module or procedure level via the Option Base statement). Note also that arrays of strings cannot be passed from Visual Basic to LF95.


Borland Delphi Information

Borland Delphi Information

Delphi Calling FortranTo create a DLL that will work with Borland Delphi, take the Fortran source (without a main program) and indicate the procedures that you want available in the DLL with the DLL_EXPORT statement, then invoke the LF95 driver like this:

LF95 source.f90 -win -dll -ml bd

Running the Delphi Calling Fortran Demo1. Compile the BDDEMO2.F90 file located in LF95’s EXAMPLES\MIX_LANG\BD direc-

tory using the -dll, -win, and -ml bd options.

2. Ensure that the resulting BDDEMO2.DLL resides either in the current working direc-tory, or in a directory that is on your path. Failure to do this will generally result in an “Debugger Kernel Error” message from the operating system.

3. Start Delphi and open the BDDEMO2.DPR project in LF95’s EXAMPLES\MIX_LANG\BD directory.

4. Run the demo (F9).

Fortran Calling Delphi DLLsBefore building the Fortran main program with LF95, you must have a DLL and import library available. Refer to your Delphi documentation for the specifics on creating a DLL. Because Delphi does not build a .LIB file for the DLL, and does not create compatible object files, the stub method must be used to create a Microsoft-compatible import library. See”Building import libraries when no object file is available” on page 47. An example of linking a Fortran program to a Delphi DLL appears in the EXAMPLES\MIX_LANG\BD directory.

When you create a Fortran procedure that references a Delphi DLL procedure you declare the Delphi procedure name with the DLL_IMPORT attribute in your Fortran code. The proce-dure may be a subroutine or function. Delphi DLL functions may only return the equivalent of default INTEGER, REAL, or LOGICAL results.

Example code:program main

implicit none

real, dll_import :: My_Dll_Routine ! case-sensitive

real :: x

x = My_Dll_Routine()

write (*,*) x

end program main



Build the Fortran program using the -ml bd option:

LF95 source.f90 -win -ml bd dll_src.lib

Where dll_src.lib is the name of the Microsoft compatible import library created by the stub method.

Running the Fortran Calling Delphi Demo1. From Delphi, open F95CALLBD.DPR in LF95’s EXAMPLES\MIX_LANG\BD

directory.

2. Build the DLL by pressing Ctrl-F9.

3. Copy F95CALLBD.DLL to LF95’s EXAMPLES\MIX_LANG\BD directory.

4. Change to LF95’s EXAMPLES\MIX_LANG\BD directory.

5. Run the batch file RUNF95CALLBD.BAT. This batch file compiles the Fortran stub code, generates an import library, and compiles the Fortran main program using the newly created import library.

6. The resulting executable, F95CALLBD.EXE is automatically run by the batch file.

Declaring your Procedure in DelphiIn your Delphi code, a procedure’s declaration will be like one of the following examples:

function my_LF95_function(var my_arg: LongInt) : LongInt; stdcall; external ‘my_dll.dll’;procedure my_LF95_subroutine( var my_arg: Single); stdcall; external ‘my_dll.dll’;

(see the relevant section below if an item on the argument list is either an array or is character datatype).

Passing Character Data in DelphiCharacter arguments are passed as strings with the length of each string appended at the end of the argument list.

Delphi has two kinds of strings: long strings and short strings, where a long string can contain a very large number of characters and its length varies dynamically as needed, and a short string has a specified length and may contain up to 255 characters. If your character argu-ment is a short string you should use the var keyword in your procedure’s declaration; omit the var keyword if your argument is a long string. Refer to the BDDEMO and BDDEMO2 pro-grams to see examples for both of these cases.

As of this writing, the following conditions apply:

• Character arguments should be declared as CHARACTER(LEN=*).


Passing Arrays in Delphi

• “Long string” character arguments should be treated as INTENT(IN).

• “Short string” character arguments may be treated as INTENT(IN OUT).

• Fortran functions returning CHARACTER data to Delphi are not supported.

Passing Arrays in DelphiBecause Delphi processes multi-dimensional arrays as an array of arrays (like C and C++) and Fortran processes arrays as multi-dimensional arrays, there are some special consider-ations in processing a Fortran array. Refer to the “Passing Arrays in C or C++” section for more information.

Calling Fortran DLL’s from .NET ApplicationsPrograms created using a .NET language dynamically load unmanaged DLL’s at runtime, so the DLL name and characteristics must be specified in the managed code. When creating a native Fortran DLL that can be called by a .NET application, compile and link with one of the following -ml options: winapi, msvc, lf95, or fc. If a version of LF95 prior to v5.7 is being used, the -ml winapi option should not be specified. DLLs built with the -ml msvb option can be called from VB.NET applications. DLLs built with the -ml options lf90, bc, or bd cannot be called from .NET languages.

For a v5.7 DLL compiled and linked with -ml lf95, or no -ml option, the cdecl calling con-vention is used.

For a v5.7 DLL compiled and linked with -ml winapi, -ml msvc, or -ml fc, the stdcall2 calling convention is used.

Fortran function results and argument types must be able to map to .NET variable types.

Example code demonstrating calling Fortran DLL’s from .NET languages exist in directories under the EXAMPLES\MIX_LANG directory. These directories all contain .NET in the direc-tory name.

Calling LF95 DLLs from Microsoft C#For DLL’s using the cdecl convention, declare the Fortran procedure in the C# code using the following syntax:

[DllImport("dll-name.dll", CallingConvention=CallingConvention.Cdecl)]public static extern return-type procedure-name_ (argument-list);

For DLL’s using the stdcall2 convention, declare the Fortran procedure in the C# code using the following syntax:

[DllImport("dll-name.dll")]



public static extern return-type procedure-name (argument-list);

Where:dll-name.dll is the pathname\file-name of the unmanaged (Win32) DLL.

return-type is "void" if calling a Fortran subroutine, otherwise the C# equivalent of the Fortran function return type.

procedure-name is the case-sensitive procedure name. If the cdecl convention is used, a trailing underscore must be appended to the procedure name.

argument-list is a managed code variable list with types mapped to Fortran dummy argument types; precede pass-by-reference parameters with "ref".

Calling LF95 DLLs from Microsoft Visual Basic .NETFor DLL’s using the cdecl convention, declare the Fortran procedure in the VB.NET code using the following syntax:

Calling a function:Class ClassName <DllImport("dll-name.dll", CallingConvention:=CallingConvention.Cdecl)> _ Shared Function proc-name_ (arg-list) as return-type End FunctionEnd Class

Calling a subroutine:Class ClassName <DllImport("dll-name.dll", CallingConvention:=CallingConvention.Cdecl)> _ Shared Sub proc-name_ (arg-list) End SubEnd Class

For DLLs using the stdcall2 convention, declare the Fortran function in the VB.NET code using the following syntax:


Calling LF95 DLLs from Microsoft Visual C++ .NET

Calling a function:Class ClassName <DllImport("dll-name.dll", CallingConvention:=CallingConvention.StdCall)> _ Shared Function proc-name (arg-list) as return-type End FunctionEnd Class

Calling a subroutine:Class ClassName <DllImport("dll-name.dll", CallingConvention:=CallingConvention.StdCall)> _ Shared Sub proc-name (arg-list) End SubEnd Class

For DLLs compiled using the -ml msvb option, declare the Fortran function in the VB.NET code using the following syntax:

Calling a function:Class ClassName Declare Auto Function proc-name Lib "dll-name.dll" (arg-list) as return-type End FunctionEnd Class

Calling a subroutine:Class ClassName Declare Auto Function proc-name Lib "dll-name.dll" (arg-list) End FunctionEnd Class


return-type is the VB.NET equivalent of the Fortran function return type.

proc-name is the case-sensitive procedure name. If the cdecl convention is used, a trailing underscore must be appended to the procedure name.

arg-list is a managed code variable list with types mapped to Fortran dummy argument types; precede pass-by-reference parameters with "ByRef".

Calling LF95 DLLs from Microsoft Visual C++ .NETFor DLLs using the cdecl convention, declare the Fortran procedure in the C++ code using the following syntax:



[DllImport("dll-name.dll", CallingConvention=CallingConvention::Cdecl)]extern "C" return-type procedure-name_ (argument-list);

For DLLs using the stdcall2 convention, declare the Fortran procedure in the C++ code using the following syntax:

[DllImport("dll-file-name.dll"]extern "C" return-type procedure-name (argument-list);


return-type is "void" if calling a Fortran subroutine, otherwise the C++ equivalent of the Fortran function return type.

procedure-name is the case-sensitive procedure name. If the cdecl convention is used, a trailing underscore must be appended to the procedure name.

argument-list is a managed code variable list with types mapped to Fortran dummy argument types; precede pass-by-reference parameters with "ref".

Calling the Windows APILF95 can directly access functions in the Windows API, with some limitations. You will need to have access to Windows API documentation and some knowledge of Windows Pro-gramming in C or C++ to take full advantage of this functionality, since the API is designed for C and C++.

Complete Windows applications can be written with Lahey Fortran 95 without resorting to using another language for the user interface. This might not be the best approach for many people, but examining how to do it can boost one's understanding of the issues, and these issues can crop up even when creating Windows applications using other approaches.

An example of this approach can be found in LF95's EXAMPLES\MIX_LANG\WINAPI directory, in the files WINDEMO.F90, WINDEMO.RC, WINDOWS.F90, and RUNWINDEMO.BAT.

The first step is to compile the file WINDOWS.F90, found in LF95’s SRC directory. Then USE the module WINDOWS_H in any procedure that will call the Windows API. WIN-DOWS.F90 is a Fortran translation of the standard windows header file WINDOWS.H, which contains definitions for various Windows parameters.

Next declare the API function with the DLL_IMPORT attribute in a type statement, for example, if you want to call the API function MessageBox:

INTEGER, DLL_IMPORT :: MessageBoxA

Names with the DLL_IMPORT declaration are case sensitive. Elsewhere in your Fortran program the names of imported procedures are case insensitive.


Calling the Windows API

Here are some more things to consider:

• Compile your code using the -ml winapi, -win, and -nvsw options.• When calling Windows API procedures from Fortran you will need to have

DLL_IMPORT statements with the names of all of the API procedures you will use. These names are case sensitive and you will need to use the correct case in the DLL_IMPORT statement. Elsewhere in your Fortran program code the case for these procedure names does not matter, though it's a good idea for clarity's sake to retain the case used in the Windows API. A good place for these DLL_IMPORT statements is in the module you create for your parameter declarations.

• If you have a resource file called MYRC.RC, compile it by adding MYRC.RC to the LF95 command line. You need to include WINDOWS.H (supplied with LF95 in the SRC directory) in your resource file. LF95's driver will call RC.EXE (the resource compiler which ships with LF95 and with various other Windows compilers) to cre-ate MYRC.RES. This will then be linked with the other objects and libraries you specified on the command line.

• Any new item you create with a #define in your resource file needs to be declared as an INTEGER parameter in your Fortran source so that it is accessible in the scoping unit in which it is referenced. It is cleanest to put all of these parameter declarations in a module.

• Void API functions must be called as subroutines from Fortran and API functions which return values must be called as functions from Fortran.

• Many of the API functions you call will need to have the letter 'A' appended to the function name. This calls the ASCII (rather than the Unicode) version of the func-tion. If the linker gives you an unresolved external message on an API function you think you've declared properly, try appending an 'A' to the name. It is a good bet that API functions that deal with character strings will require the 'A'.

• API function arguments that do not map to Fortran intrinsic types need to be declared in your Fortran program. Declare structure arguments as SEQUENCE derived types. Declare pointers (to anything, including strings) as INTEGERs.

• Whenever you pass a numeric argument use CARG. For example:call PostQuitMessage(carg(0))

• Whenever you pass a pointer argument use CARG(POINTER(argument)) instead of argument. For example:

type (WNDCLASS):: wcresult=RegisterClassA(carg(pointer(wc))

• Whenever you pass a pointer to CHARACTER, remember that C requires null-ter-minated strings. CARG will make a copy of a string and null-terminate it for you. However, because a copy is made, the original value cannot be changed by the func-tion you call. For example:

result = SendDlgItemMessageA(carg(hwnd), & carg(IDC_LIST1, & carg(LB_ADDSTRING), & carg(0), & carg(string))



To pass a string you want the function to change, null-terminate the string manually and then use CARG of the POINTER. Note that you can use CHAR(0) to generate a null. For example:

character(len=81) :: mystr ! leave space for trailing null

mystr = trim(mystr(1:80)) // char(0)

call SomeAPIRoutineA(carg(pointer(mystr)))

• Wherever on the right-hand side of a C assignment statement you would use the ampersand character to get the address of something, you will need to use POINTER in your Fortran program. For example:

wc%lpszClassName = pointer(szClassName)

is equivalent to the C:

wc.lpszClassName = &szClassName;

• Callback procedures, where Windows will be calling a Fortran procedure, must not be module procedures or internal procedures.

• To set up a callback procedure, include an interface block defining the callback pro-cedure and declaring it to be ml_external. Then use the POINTER of the procedure name. For example:

interface

integer function WndProc(hwndByValue, &

messageByValue, &

wParamByValue, &

lParamByValue)

ml_external WndProc

integer :: hwndbyValue, messageByValue, &

wParamByValue, lParamByValue

end function WndProc

end interface

type(WNDCLASS):: wc

wc%lpfnWndProc = offset(WndProc)

• Arguments to a Fortran callback procedure are values (C passes by value). To make these work in your callback procedure, assign the pointer of these values to local variables. For example:


Calling assembly language procedures

integer function WndProc(hwndByValue, &

messageByValue, &

wParamByValue, &

lParamByValue)

implicit none

ml_external WndProc

integer :: hwnd, message, wParam, lParam

integer :: hwndByValue, messageByValue

integer :: wParamByValue, lParamByValue

hwnd = pointer(hwndByValue)

message = pointer(messageByValue)

wParam = pointer(wParamByValue)

lParam = pointer(lParamByValue)

! do not reference the ByValue arguments from here on !

• See windows.f90 in the SRC directory for examples of functions, types, and defi-nitions for use in Windows API programming.

Calling assembly language proceduresThe following information is provided courtesy of Kenneth G. Hamilton, 12-Oct-1998.

LF95 ConventionsThis section is intended to assist the experienced assembly language programmer in writing subprograms that can be called by LF95-compiled Fortran code. The examples that follow were processed by Microsoft MASM v6.11a, although any recent assembler will likely suf-fice. In addition to this information, you should also have on hand appropriate documentation for your assembler. The examples in this writeup can be found in subdirec-tories EXAMPLES\MIX_LANG\ASSEMBLY\EX1, EX2, EX3, etc.

Each sample program can be compiled and linked by using the GEN.BAT file that accompa-nies it.

Entry Point Name ManglingWhen it compiles Fortran source code, LF95 shifts the names of subroutines and functions into lower case letters, and attaches an underscore symbol (_) both before and after each name. As an example, suppose that an LF95 program calls subroutine RAINBOW. If that routine is written in assembly language, then it must have an entry point called _rainbow_ on a PROC or LABEL statement, and that name must declared to be a PUBLIC symbol.



Saved RegistersLF95 requires that subroutines and functions preserve the value of the EBX, ESI, and EDI registers. If any of these registers are used in an assembly-language routine, they can be saved by pushing them upon entry, and then popping them before returning.

Argument PassingLF95 passes numeric and logical arguments by pushing their addresses onto the stack, from right to left. Each address is a four-byte quantity, so that, upon entry to a subprocedure the first argument's address is located at ESP+4, the second at ESP+8, the third at ESP+12, and so on. (The ESP register itself contains the address that control will return to in the calling routine, upon subprogram termination.)

Generally, the best procedure (and this is what LF95 itself does) is to push EBP onto the stack, and then move the contents of the ESP register into EBP. This is often known as the ‘preamble’ of the routine. The arguments can then be accessed using EBP instead of ESP, and any additional pushing or popping will not result in any confusion about where the argu-ment addresses are. Since pushing EBP onto the stack changes the stack pointer by four bytes, the first argument's address will be in EBP+8, the second argument's in EBP+12, the third's in EBP+16, and these offsets from EBP will not be altered by any local activity involv-ing the ESP register.

For CHARACTER-valued arguments, the length of the string must also be passed. This is done by treating the lengths of the CHARACTER arguments as though they were extra parameters following the normal visible ones, and passing them by value. The term ‘by value’ in this context means that the actual length is pushed, rather then the address of the length. These length parameters are treated as though they were to the right of the actual parameters in the call, and so they are actually pushed first, and are at higher offsets relative to EBP.

Passing Arguments to SubroutinesIt is often easiest to learn a programming method by studying examples, and so we will now show and examine several cases in which a Fortran program calls an assembly language subprogram.

First, the following main program (ADDMAIN) passes two INTEGER variables to a Fortran subroutine (FORADD), where they are added, with their sum being returned as a third variable.

Example 1: Simple Addition. PROGRAM ADDMAIN integer :: i,j,k,l i = 17 j = 24 call foradd(i,j,k) print *, 'i,j,k=',i,j,k


Passing Arguments to Subroutines

i = 52 j = 16 call asmadd(i,j,l) print *, 'i,j,l=',i,j,l stop end SUBROUTINE FORADD(II,JJ,KK) kk = ii+jj return end

You should note that ADDMAIN also calls a second subroutine, ASMADD. Here it is:

TITLE ASMADD .386 .MODEL FLAT;_ACODE SEGMENTPARA USE32 PUBLIC 'CODE' ASSUME CS:_ACODE PUBLIC _asmadd_ ; Entry point name_asmadd_ PROC NEAR ; Start of procedure push ebp ; Save EBP mov ebp,esp ; Will use EBP for args push ebx ; Must save EBX mov eax,[ebp+8] ; 1st arg addr mov ecx,[ebp+12] ; 2nd arg addr mov edx,[ebp+16] ; 3rd arg addr mov ebx,[eax] ; 1st arg value mov eax,[ecx] ; 2nd arg value add eax,ebx ; Form I+J mov [edx],eax ; Store into K pop ebx ; Restore saved EBX mov esp,ebp ; Restore stack pointer pop ebp ; Restore base pointer ret ; Return to caller_asmadd_ ENDP ; End of procedure_ACODE ENDS ; End of segment END

ASMADD is the assembly-language translation of FORADD: it also takes three variables, adds the first two, and returns the result in the third one. Examining ASMADD, we can see that once the preamble is completed, the addresses of the arguments are accessible to the assembly-language routine in EBP+8, EBP+12, and EBP+16. Since the EBX register is used in the processing, its contents must be preserved by being pushed onto the stack before it is clobbered, and popped off later.

LF95 assumes that the caller will fix the stack, i.e., remove the argument address pointers. As a result, the return to the calling routine is accomplished by means of a simple RET instruction.



Example 2: Using local data.Now, let us examine a case in which a subroutine contains some local data. The main pro-gram MULMAIN calls two subroutines, FORMUL (written in Fortran), and ASMMUL written in assembly language. Both FORMUL and ASMMUL do the same thing: multiply the first argument by 7, add 3, and then return the result as the second argument. This is the Fortran part:

PROGRAM MULMAIN integer :: i,j,k,l i = 5 call formul(i,j) print *, 'i,j=',i,j k = 3 call asmmul(k,l) print *, 'k,l=',k,l stop end SUBROUTINE FORMUL(II,JJ) jj = 7*ii + 3 return end

Here is the assembly-language subroutine ASMMUL, with two constants m1 and m2 stored in a local data area.

TITLE ASMMUL .386 .MODEL FLAT;_ACODE SEGMENT PARA USE32 PUBLIC 'CODE' ASSUME CS:_ACODE, DS:_ADATA PUBLIC _asmmul_ ; Entry point name_asmmul_ PROC NEAR ; Start of procedure push ebp ; Save base pointer mov ebp,esp ; Save stack pointer mov eax,[ebp+8] ; 1st arg addr mov eax,[eax] ; 1st arg EAX=I mov ecx, m1 ; 7 into ECX mul ecx ; 7*I is in EAX add eax, m2 ; 7*I+3 is in EAX mov edx,[ebp+12] ; 2nd arg addr mov [edx],eax ; Store in 2nd arg (J) mov esp,ebp ; Restore stack pointer pop ebp ; Restore base pointer ret _asmmul_ ENDP_ACODE ENDS;_ADATA SEGMENT PARA USE32 PUBLIC 'DATA'



m1 dd 7m2 dd 3_ADATA ENDS; END

The two variables are initialized to values of 7 and 3, and are not altered. Quantities stored in this manner could be changed during the course of computation, if required. Alternatively, this routine could have been written with the constants 7 and 3 being coded as immediate data in the MOV and ADD instructions that use them.

Example 3: Using floating-point arithmetic.Floating point arithmetic is also possible in an assembly language routine that is called from an LF95 program. Here is an example of a main program (FLTMAIN) that calls two func-tionally-identical subroutines, FORFLT and ASMFLT, which are written in Fortran and assembly lanaguage, respectively.

PROGRAM FLTMAIN real :: x, y, z x = 3.0 y = 8.5 call forflt(x,y,z) print 20, x,y,z 20 format (' x,y,z=',3F10.4) x = 4.5 y = 7.1 call asmflt(x,y,z) print 20, x,y,z stop end SUBROUTINE FORFLT(XX,YY,ZZ) zz = 3.1*xx + yy + 7.6 return end

This is the assembly language routine, and we can see that REAL variables are also passed as addresses, located in EBP+8, EBP+12, EBP+16, etc.

TITLE ASMFLT .386 .MODEL FLAT;_ACODE SEGMENT PARA USE32 PUBLIC 'CODE' ASSUME CS:_ACODE, DS:_ADATA PUBLIC _asmflt_ ; Entry point name_asmflt_ PROC NEAR ; Start of procedure push ebp ; Save base pointer mov ebp,esp ; Save stack pointer mov eax,[ebp+8] ; Addr X mov ecx,[ebp+12] ; Addr Y



mov edx,[ebp+16] ; Addr Z fld dword ptr d1 ; Load 3.1 fmul dword ptr [eax] ; 3.1*X fadd dword ptr [ecx] ; 3.1*X+Y fadd dword ptr d2 ; 3.1*X+Y+7.6 fstp dword ptr [edx] ; Store into Z mov esp,ebp ; Restore stack pointer pop ebp ; Restore base pointer ret _asmflt_ ENDP_ACODE ENDS;_ADATA SEGMENT PARA USE32 PUBLIC 'DATA'd1 dd 3.1d2 dd 7.6_ADATA ENDS; END

In assembly language, it is necessary to access the values of the variables using the keywords DWORD PTR for REAL(KIND=4) and QWORD PTR for REAL(KIND=8) variables.

Example 4: Using COMMON blocks.If it is necessary for an assembly language subroutine to access the contents of a COMMON block, then we must find the starting address of that block.

The starting address of a named COMMON is put in a global variable; the name of that vari-able is composed by converting the COMMON block's name to lower case letters, and then attaching an underscore before and after the name. Thus, the starting address of a COMMON block that is named ZOOM can be found in the global variable _zoom_ . The starting address of blank COMMON is placed in the global variable __BLNK__. (Note that there are two underscore symbols both before and after the word ``BLNK.'')

In the following example, both blank COMMON and COMMON/RRR/ are passed to a For-tran subroutine (FORCOM) and its assembly language equivalent (ASMCOM), where some minor calculations are performed.

PROGRAM CMNMAIN common i,j,k common /rrr/ x,y,z i = 4; j = 17; k = 0 x = 1.6; y = 3.7; z = 0.0 call forcom print 10, i,j,k 10 format (' i,j,k=',3I6) print 20, x,y,z 20 format (' x,y,z=',3F10.4) i = 4; j = 17; k = 0 x = 1.6; y = 3.7; z = 0.0



call asmcom print 10, i,j,k print 20, x,y,z stop end SUBROUTINE FORCOM common i,j,k common /rrr/ x,y,z k = 5*i + j z = x*y return end

This is ASMCOM, the assembly language subroutine that manipulates variables in the two COMMON blocks.

TITLE ASMCOM .386 .MODEL FLAT;BLNKCOM STRUCTi dword ?j dword ?k dword ?BLNKCOM ENDS; EXTERN __BLNK__:BLNKCOM;RRRCOM STRUCTx real4 ?y real4 ?z real4 ?RRRCOM ENDS; EXTRN _rrr_:RRRCOM;_ACODE SEGMENTPARA USE32 PUBLIC 'CODE' ASSUME CS:_ACODE, DS:_ADATA PUBLIC _asmcom_ ; Entry point name_asmcom_ PROC NEAR ; Start of procedure push ebp ; Save EBP mov ebp,esp ; use EBP for args mov eax, dword ptr __BLNK__.i ; Get I mov ecx, m1 ; Load 5 mul ecx ; Form 5*I add eax, dword ptr __BLNK__.j ; 5*I+J mov dword ptr __BLNK__.k,eax ; Store into K fld dword ptr _rrr_.x ; Load X fmul dword ptr _rrr_.y ; Form X*Y



fstp dword ptr _rrr_.z ; Z=X*Y

mov esp,ebp ; Restore stack pointer

pop ebp ; Restore base pointer

ret ; Return to caller

_asmcom_ ENDP ; End of procedure

_ACODE ENDS ; End of segment

;

_ADATA SEGMENT PARA USE32 PUBLIC 'DATA'

m1 dd 5

_ADATA ENDS

;

END

The starting addresses of the COMMON blocks are obtained by using EXTERN directives to connect to the global values. The individual variables within a COMMON block can then be accessed as STRUCTs that are written so as to match the layout of the Fortran code's COMMON declarations. Each COMMON block must consist of a STRUCT definition, plus an EXTERN declaration to connect it to the global data object.

Example 5: CHARACTER arguments.Type CHARACTER variables are passed to subroutines as two arguments: the starting address of the string, and the string's length. The two arguments are not, however, pushed consecutively onto the stack. Rather, the address pointer is pushed in the usual order, and then after all arguments have been passed, the lengths of any CHARACTER arguments are passed by value.

Here is an example of a main program (CHRMAIN), that calls a Fortran subroutine (FORCAPS), and its assembly language equivalent (ASMCAPS). Both FORCAPS and ASMCAPS take two CHARACTER arguments; the first argument is converted into all upper case letters, and then returned in the second argument.

PROGRAM CHRMAIN

character (len=20) :: line1, line2, line3

line1 = 'This is a message'

line2 = 'zzzzzzzzzzzzzzzzzzzz'

line3 = 'aaaaaaaaaaaaaaaaaaaa'

call forcaps(line1,line2)

print 20, line1

print 20, line2

20 format (1X,A)

call asmcaps(line1,line3)

print 20, line1

print 20, line3

stop

end



SUBROUTINE FORCAPS(L1,L2)

character*(*) :: l1, l2

n = len(l1) ! Converts all

do i=1,n ! chars to caps

ic = ichar(l1(i:i))

if (ic.ge.97 .and. ic.le.122) ic = ic-32

l2(i:i) = char(ic)

enddo

return

end

This is the assembly language string capitalization routine.

TITLE ASMCAPS

.386

.MODEL FLAT

;

_ACODE SEGMENTPARA USE32 PUBLIC 'CODE'

ASSUME CS:_ACODE

PUBLIC _asmcaps_ ; Entry point name

_asmcaps_ PROC NEAR ; Start of procedure

push ebp ; Save EBP

mov ebp,esp ; Will use EBP for args

push esi ; Must preserve ESI

push edi ; Must preserve EDI

;

mov esi,[ebp+8] ; 1st string addr (L1)

mov edi,[ebp+12] ; 2nd string addr (L2)

mov ecx,[ebp+16] ; 1st string length

cmp ecx, 0 ; Length nonpositive?

jle Exit ; Yes, so return

;

Looper: mov al, [esi] ; Get char from L1

cmp al, 97 ; Below "a"?

jl PutIt ; Yes, so no conversion

cmp al, 122 ; Above "z"?

jg PutIt ; Yes, so no conversion

sub al, 32 ; Change LC to UC

PutIt: mov [edi], al ; Store

inc esi ; Point to next char

inc edi ; Point to next target

loop Looper ; Loop until done

;



Exit: pop edi ; Restore saved EDI pop esi ; Restore saved ESI mov esp,ebp ; Restore stack pointer pop ebp ; Restore base pointer ret ; Return to caller_asmcaps_ ENDP ; End of procedure_ACODE ENDS ; End of segment END

Note that the starting addresses of the arguments are stored in EBP+8 and EBP+12, while the lengths of the two CHARACTER variables are in EBP+16 and EBP+20. In this code, we do not make use of the length of the second string, assuming it to be equal to that of the first one.

Since we use the ESI and EDI registers in this subroutine, we save their previous values on the stack and restore them before returning.

Returning Values from Functions

LF95 Function ConventionsThe methods for passing arguments and COMMON blocks to a FUNCTION are identical to those described above for a SUBROUTINE. The only difference in the calling sequence is that a FUNCTION returns a value, and the method that is used to send the result back to the calling routine depends upon the data type of that value.

INTEGER-valued FUNCTIONs return values using CPU registers, so that the return value for one-byte, two-byte, and four-byte functions are returned in AL, AX, and EAX, respectively.

Four-byte and eight-byte REAL FUNCTIONs use the top of the floating-point unit stack, ST(0) for return of values. The only difference in the assembly language access of these vari-able types is that the former require DWORD PTR, while the latter use QWORD PTR when loading to and storing from the FPU. These conventions are summarized in Table 8 on page 81.



Example 6: A COMPLEX FunctionWhen an LF95 program calls a COMPLEX-valued function, it first pushes the argument addresses onto the stack, and then also pushes the address of a place where the function should store its return value. Thus, after the function preamble (where the contents of ESP are stored into EBP), EBP+8 will contain the address of the return buffer, and the normal argument pointers will start at EBP+12.

Here is an example of a program that passes a COMPLEX variable to a COMPLEX-valued Fortran function CXFFUN that returns two times its argument.

PROGRAM CXMAIN

complex :: a, b, c, cxffun, cxafun

a = (1.0,2.0)

b = cxffun(a)

c = cxafun(a)

print *, 'a=',a

print *, 'b=',b

print *, 'c=',c

stop

end

Table 8: FUNCTION Return Mechanisms

Function Type Kind No. Location of Return Value

INTEGER 1 AL

INTEGER 2 AX

INTEGER 4 EAX

LOGICAL 1 AL

LOGICAL 4 EAX

REAL 4 ST(0)

REAL 8 ST(0)

COMPLEX 4 Address on stack

COMPLEX 8 Address on stack

CHARACTER all Address & length on stack



FUNCTION CXFFUN(A) complex :: a, cxffun cxffun = a+a return end

The above program also calls a COMPLEX-valued assembly language function CXAFUN, that performs exactly the same operation as CXFFUN, i.e., it returns double the argument.

TITLE CXAFUN .386 .MODEL FLAT;_ACODE SEGMENT PARA USE32 PUBLIC 'CODE' ASSUME CS:_ACODE PUBLIC _cxafun_ ; Entry point name_cxafun_ PROC NEAR ; Start of procedure push ebp ; Save EBP mov ebp,esp ; Will use EBP for args; mov eax, [ebp+12] ; Argument address fld dword ptr [eax] ; Get real part fadd dword ptr [eax] ; Double it fld dword ptr [eax+4] ; Get imag part fadd dword ptr [eax+4] ; Double it; mov eax, [ebp+8] ; Return buffer address fstp dword ptr [eax+4] ; Store imag part fstp dword ptr [eax] ; Store real part; mov esp,ebp ; Restore stack pointer pop ebp ; Restore base pointer ret ; Return to caller_cxafun_ ENDP ; End of procedure_ACODE ENDS ; End of segment END

Looking at this function, we can see that the single argument's address is stored in EBP+12. That is the address of the real part of the argument, with the imaginary part being stored four bytes higher in memory.

Both parts of the argument are copied into the FPU and doubled. The results are then stored into the return buffer, whose address is found at EBP+8. That is, of course, the address of the real part and the imaginary component is stored four bytes higher.

Example 7: A CHARACTER FunctionA somewhat more complicated mechanism is used for CHARACTER-valued functions. After the argument information has been pushed on the stack, they are followed by the length and starting address of the memory buffer that will accept the result. As a consequence, the



return buffer's address can be found in EBP+8, and its length in EBP+12. The address of the first argument is then moved up to EBP+16, and any other arguments follow in the usual manner.

Here is a Fortran main program that sets a CHARACTER variable equal to the string ``Hello,'' and then calls a Fortran function (FFUN) that returns a capitalized form of the string. The program then calls an assembly language function (AFUN) that returns a decap-italized version.

PROGRAM CHMAIN character*20 a, b, c, ffun, afun a = 'Hello' b = ffun(a) c = afun(b) print 20, a, b, c 20 format (' a = ',A/' b = ',A/' c = ',A) stop end CHARACTER*20 FUNCTION FFUN(A) character*(*) a n = len(a) do i=1,n ic = ichar(a(i:i)) if (ic.ge.97 .and. ic.le.122) ic = ic-32 ffun(i:i) = char(ic) enddo return end

This is the CHARACTER-valued assembly language function that is used by the program above:

TITLE AFUN .386 .MODEL FLAT;_ACODE SEGMENT PARA USE32 PUBLIC 'CODE' ASSUME CS:_ACODE PUBLIC _afun_ ; Entry point name_afun_ PROC NEAR ; Start of procedure push ebp ; Save EBP mov ebp,esp ; Will use EBP for args push esi push edi; mov edx, [ebp+12]; Length of return buffer mov eax, [ebp+20]; Length of argument cmp edx, eax ; Which is smaller? jg L10 ; Return buffer



mov ecx, edx ; Get arg length

jmp L20

L10: mov ecx, eax ; Get ret buf length

L20: cmp ecx, 0 ; Length nonpositive?

jle L90 ; Yes, so return

;

mov esi, [ebp+16]; Addr of argument

mov edi, [ebp+8] ; Addr of ret buf

L30: mov al, [esi] ; Get char from L1

cmp al, 65 ; Below "A"?

jl L40 ; Yes, so no conversion

cmp al, 90 ; Above "Z"?

jg L40 ; Yes, so no conversion

add al, 32 ; Change UC to LC

L40: mov [edi], al ; Store

inc esi ; Point to next char

inc edi ; Point to next target

loop L30 ; Loop until done

;

L90: pop edi ; Restore saved EDI

pop esi

mov esp,ebp ; Restore stack pointer

pop ebp ; Restore base pointer

ret ; Return to caller

_afun_ ENDP ; End of procedure

_ACODE ENDS ; End of segment

END

The sole argument is passed with its starting address in EBP+16, and its length in EBP+20 --- remember that if there are several arguments, then the CHARACTER lengths follow the entire list of addresses. The return buffer, the place where the function should store its return value is communicated by its starting address (in EBP+8) and length (in EBP+12).


4 Editing and Debugging with ED

Lahey ED for Windows (ED) is a Fortran-smart development environment. You can edit, compile, link, and run your programs all from within ED. ED offers sophisticated editing features like syntax highlighting, intelligent procedure browsing, code completion, macros, drag and drop, as well as the standard editing features you are accustomed to. After a com-pilation, ED highlights the exact location of programming errors diagnosed by the compiler.

You can also debug Windows programs with ED. While debugging, you can watch the val-ues of variables change during program execution and set breakpoints with a mouse click.

This chapter assumes a basic familiarity with Windows. It presents an overview of ED’s functionality. For detailed information, please see ED’s on-line help.

Setting Up and Starting ED

StartupED must be run from Windows. Start ED by double-clicking the Lahey ED for Windows icon.


Chapter 4 Editing and Debugging with ED

Exiting EDTo exit from ED, choose File|Exit from the menu, double-click the system menu icon in the top left corner, or press Alt-F4.

Always exit ED before turning off your computer. ED checks for unsaved changes and enables you to save these before exiting.

The ED Screen

The Menu BarED features pull-down menus from which the various ED commands can be invoked. To open a menu, click on item on the menu bar with the mouse or press Alt-underlined letter. Select a command by clicking on it with the mouse or by pressing underlined letter.

Docked Toolbar

Floating Toolbar

Menu Bar

Status Bar

Window Tabs

Toolbar Buttons

Current Window


The Status Bar

The Status BarThe status bar displays information about the current state of ED. It is more than informa-tional. Click on:

• Insert/Overtype/View to toggle Insert/Overtype/View mode. • the Word Wrap Status to toggle word wrap on or off. • the Macro Status to play the current macro.• the Time and Date to change the time and date format.• the Cursor Line and Column to go to a particular line and column.• Edited to save the current file.• the Filename to change the active window.• Select Toolbar to select or deselect toolbars.

The Text BarED’s Text Bar provides a visual reminder of lines that have been edited and lines that have been added. When debugging (see ”Debugging” on page 95), the Text Bar marks the cur-rent line and lines with breakpoints. You can activate the Text Bar by right-clicking on white space to the left of any line, or by selecting Options|Configuration|Display and checking the Text Bar Visible box.

ToolbarsToolbars provide a quick way to issue commands with the mouse. ED comes with a variety of toolbars. Display different toolbars by pressing the Select Toolbar button on the status bar.

Point to a toolbar button to pop up quick help on that button. To issue the command, left-click.

Edited Line

Breakpoint

Insert/OvertypeView Mode

WordWrap

MacroStatus Time and Date Cursor Line and Column

Edited?

Filename

WindowNumber Select

Toolbar

New Line

Current Line



The Window BarED’s window bar makes switching between open files easy. Left-click on a window tab to make that window current. Right click on a tab to perform other operations on that file.

Getting HelpGet general help on ED by pressing F1. Get context-sensitive help by pressing Shift-F1. Both general and context-sensitive help are also available through the Help menu. A quick tour of ED is available through Help|Help Contents. This is especially valuable if you are new to ED and would like to get a glimpse of the features it offers. You can also view a quick reference to ED’s shortcut keys by pressing Alt-Q or by selecting Help|Quick Reference.

Managing Files

Creating A File From ScratchTo create a new file, select File|New. Select a file type (file extension). You now have an empty file you can edit. Save the file by selecting File|Save or by clicking on the Save file button on the docked toolbar. You can also create a new file by clicking on the Open File for Editing button on the docked toolbar. The File|Open dialog box appears. Select a drive and directory and enter a name for the file. Click OK to create the file.


Opening A File

Opening A FileOpening a file that already exists is also done using File|Open. You can choose to select directories and files either from a list of those that exist or from a history of those most recently used.

Files are opened in edit mode by default. To open a file in view-only mode, select File|View. Toggle between edit and view modes by pressing Alt-F3.

If you use include files, you can view them by right clicking on the filename in the INCLUDE line in your code.



Syntax HighlightingED highlights Fortran syntax elements, like keywords, literal constants, and comments, with different colors. This facility can be customized in several ways. To change the default col-ors, select Options|Color Setup. To change the elements that ED highlights or to add new elements of your own, edit the file lang_for.iii, where iii are your initials.

By default, only files that end in .for, .f90, and .f use Fortran syntax highlighting. Other file extensions are set to use no syntax highlighting. You can turn on syntax highlighting for some 30 other languages by selecting Options|File Extension Setup. Only files setup with Fortran syntax highlighting or with no syntax highlighting can be saved, however.

NavigationAfter you have opened a file, move through it using:

• the normal keyboard navigation keys (PageUp, PageDown, Home, End, etc.)

• the mouse on the scroll bar

• Goto|... to jump to a particular kind of location. The Goto menu lists many loca-tions to jump to, most with quick keyboard equivalents.

Previous/Next ProcedureYou can quickly move though your file by jumping from procedure to procedure using the Ctrl-PageUp and Ctrl-PageDown keys.

Function/Procedure ListED will create a list of procedures in your file if you:

• Choose Goto|Function List;

• Press Alt-F1; or

• Click the Function/procedure list button on the toolbar

You can then jump directly to any procedure by double clicking on its name in the Function/procedure list.


Find

FindThe Search menu provides a variety of ways to find and optionally replace text. You can search for exact text or use regular expressions, where wildcard characters (* and ?) can be inserted in your search string. You can also search incrementally. Incremental search finds the next occurrence of text as you type it.

Matching Parentheses and StatementsYou can move automatically to a matching object (a parenthesis or statement) by right click-ing on an object. For example, in an expression, right-clicking on a parenthesis will jump to the matching parenthesis. This is a real time-saver in putting together complicated error-free expressions. Right-clicking on a DO statement jumps to the corresponding END DO state-ment. Right-clicking on an IF statement jumps in succession to any ELSE or ELSE IF statements and ultimately to the corresponding END IF statement.

EditingTo toggle between edit and view modes use the Alt-F3 key. When in view mode the file is protected from changes and is not locked, permitting other people to view the file at the same time.

Undo and RedoYou can undo any editing or cursor movement in ED. To undo the previous operation, select Edit|Undo or press Ctrl-Z. To redo the last operation you have undone, select Edit|Redo or press Ctrl-Y.

Extended CharactersTo type characters outside the range of your keyboard:

• Be sure the NumLock key is on.

• Type Alt-0ANSI character code to enter Microsoft Windows ANSI font characters above 127.

• Type Alt-OEM character code to enter DOS extended characters above 127.

• To enter characters below 32 such as ̂ A, ̂ B, ̂ C, etc., select Edit|Verbatim Character, then type the character. This prevents the control key sequence from being inter-preted as an ED command.



BlocksA block is an area of marked text. Once marked, a block can be deleted, moved, copied, searched, sorted, or printed.

Block OperationsED recognizes three kinds of blocks: stream, line, and column:

• Stream blocks are the usual Windows marked blocks. They begin and end at any locations you choose and include all characters in-between.

• Line blocks mark whole lines.

• Column blocks mark a rectangular area.

Marking a Block with the KeyboardPosition the cursor at the start of the block. Select Block and then Stream Block, Line Block, or Column Block. Expand the block using the arrow keys, PageUp, and PageDown.

Marking a Block with the MouseSimply click and drag to mark a block with the mouse. To toggle between the three different kinds of blocks, click the right mouse button while still holding down the left mouse button.

Marking a Word or LineTo mark a word, double-click on the word. Double click in white space left or right of a line to mark the whole line.

Drag and DropYou can move a marked block to a new location by clicking on the marked block, holding the mouse button down while you move the block, then releasing the mouse button at the desired location. You can copy rather than move a block by holding down the control key while you drag and drop.

Coding ShortcutsWords or constructs that you type repeatedly can be entered automatically or finished for you by ED.

TemplatesTemplates are abbreviations for longer sequences of characters. These sequences can be one or a few words or can comprise several lines. Choose Options|Language Words & Tem-plates then press Ctrl-PageDown to view the Fortran templates. When ED is installed a file called lang_for.iii (where iii are your initials) is set up. To modify existing tem-plates or add new ones, edit this file.


Smartype

Templates are expanded by pressing Esc or Space after typing a template abbreviation. You can specify the number of characters before Esc or Space will cause template expansion by selecting Options|File Extension Setup|Templates & Word Wrap.

SmartypeSmartype recognizes words you have already typed in your file. If you type the first few characters of a word that appears earlier in the file, then press Esc or Space, the word will be automatically completed for you. If there is an ambiguity you will be presented with a menu of words to select from.

Smartype can be deactivated for the Space key by turning off Space does Smartype in Options|File Extension Setup|Templates & Word Wrap.

Case ConversionCase conversion changes the case of words you type to match instances of words earlier in the file or to match words in the lang_for.iii file. In this way ED ensures consistency in capitalization.

Case conversion can be toggled off or on in Option|File Extension Setup.

Code CompletionCode completion finishes open nesting levels introduced by keywords or parentheses. Code completion is activated with the Esc key. For example, if you’ve typed:

a = b * ( c + ( d - e

pressing Esc once will give

a = b * ( c + ( d - e )

and pressing Esc again will give

a = b * ( c + ( d - e ) )



Compiling from ED

Compiling Your ProgramThere are two ways of compiling your program while in ED. You can click on the Lahey LF95 button from the toolbar, or select Tools|Programs|Lahey/Fujitsu LF95|Run. When you do so, a window will appear that captures the compiler’s output and shows the compiler’s progress through your source file. Pressing the F4 key will tile the source and compile windows.

Alternately, you can select the DOS button and compile as described in ”Developing with LF95” on page 11. Redirecting the compiler’s output to the errs.iii file (where iii are your initials) will enable you automatically to locate errors in your source, as described below.

Locating ErrorsED automatically synchronizes your program source with errors detected by the compiler. To browse through errors, choose Goto|Next Error or Goto|Previous Error, click on the next or previous error button on the toolbar, or press Alt-UpArrow or Alt-DownArrow. ED automatically moves the cursor to the appropriate location in your source file.


Changing Compiler Options

Changing Compiler OptionsTo change the LF95 compile line used by ED, select Tool|Programs, then select the 'General' radio button, then select Lahey/Fujitsu LF95|Edit. The following variables may be used in the Command Line and Working Directory fields.

DebuggingLahey ED for Windows’ integrated debugger can run your program, set breakpoints, step a line at a time, view the values of variables in your program in several different ways, and change the values of variables while running your program. The current executable line and any breakpoints are indicated with markers in the Text Bar (see ”The Text Bar” on page 87).

Table 9: Command Line Variables

Variable Evaluates to

<NAME> Name of the current file including drive and path.

<PATH> Drive and path for the current file.

<FILE>Filename of current file without drive\path and file extension.

<EXT> Filename extension.

<CWD> Current working directory.

<ED_DIR> ED executable’s directory.

<ENTER> Prompts the user for a filename.

<1> User’s response from first <ENTER>.

<2> User’s response from second <ENTER>.

<3> User’s response from third <ENTER>.

<DATE> Current system date.

<INITIALS> Your initials.

<WORD> The word at the current cursor position.



Starting the DebuggerNote that with version 5.5 of LF95, the Lahey/ED debugging facility is off by default and is replaced by WinFDB. However, you can still use the Lahey/ED debugger by selecting the SOLD95 Toolbar from within ED using Options|Toolbars.

Before debugging your program you must compile it using the -g and -winconsole or -win options (see “Changing Compiler Options”, above, and ”Compiler and Linker Options” on page 20). The -g option creates an additional file with debugging information. This file ends with the extension .ydg. The -win or -winconsole option creates a Win-dows executable file. Start debugging by clicking on the Debug Program button in the Lahey Fortran toolbar, or by selecting Tool|Debug. Note that Lahey ED can be used to debug both LF95 and LF90 programs. If you will use LF95’s Lahey ED to debug LF90 exe-cutables, you must first delete any .ydg files that exist for these executables in the same directory.

It is most convenient always to have the Lahey Fortran toolbar visible while debugging. When prompted, enter the name of the executable file, including the filename extension (.exe) and, if the file is not in ED’s current directory, a path. For example, if the executable file myprog.exe is in a directory called “programs” below the root, you would enter

\programs\myprog.exe

ED will expand the Text Bar and put the current line icon next to the first executable line in your program. It will also open the SOLD95W Output Window so that you can view actions performed by the debugger. Once your program is loaded, click on the Debug Program but-ton again to bring up the debug menu. You can also bring up the debug menu by selecting Tool|Debug or by right-clicking in ED’s Text Bar.


Running Your Program

Running Your ProgramTo run your program, select Run Program from the debug menu, press the F6 key, or click on the Run Program button. Just running your program is not particularly useful. You will want your program to stop occasionally by setting breakpoints or by running a line at a time. In this way you can inspect or change the values of variables at troublesome locations in your program.

To run to a particular line in your program, click on that line, then select Run to Current Line from the debug menu.

Running a Line at a TimeTo execute the current executable line in your program (marked with the current line marker in the Text Bar), click on either the step Into or Step Over button, or select Step Into or Step Over from the debug menu. If the current line is a subprogram invocation, Step Into will execute the current line and move the current line marker to the first executable line in the subprogram; Step Over will execute the entire invoked subprogram and move the current line marker to the next executable line in the current subprogram.

Setting BreakpointsOften when debugging you will want to have your program stop at a particular location in your source code, or when a particular condition occurs. Such a stopping place is called a breakpoint. To set a breakpoint, click on the Checkpoints button, or select Checkpoints from the debug menu. The following dialog box displays:



To set a breakpoint on entry to a particular program unit, click on the On Program Unit Entry checkbox, select the program unit from the list of program units, then click on Set Breakpoint. The breakpoint will display in the Checkpoints list. You can remove a breakpoint by highlighting it in the list and clicking Remove.

To set a breakpoint on a particular line, first click on that line in your source, open the Check-points dialog and click the At Line: checkbox. Then click on Set Breakpoint. A shortcut for this procedure is to simply left-click in the Text Bar next to the desired line.

To set a breakpoint on a particular condition, click the If: checkbox. You can set break-points based on whether a condition holds true, such as if a is greater than 100, or based on when a value changes.

You can remove all breakpoints at once by clicking on the Remove All button in the Check-points dialog.


Displaying the Values of Variables

Displaying the Values of VariablesValues of variables can be displayed three different ways. To display the value of a scalar variable of an intrinsic type (REAL, COMPLEX, INTEGER, LOGICAL, or CHARACTER, as opposed to a derived type), simply right click on the variable name. A box will appear with the name of the variable and its value.

To display the value of any variable, including derived types and arrays and combinations thereof, click on the Display Variable button or select Display Variable from the debug menu. Select the variable from the list of variables provided. The name and value of the variable appear in the SOLD95W Output Window.

To watch values of variables change as you step through your code, open the Watches Dialog by clicking on the Open Watches Dialog button or by selecting Open Watches Dialog from the debug menu. A Dialog like the following displays:

In the above Watch Dialog, GAME_BOARD is an array. To expand the values of all elements in the array, click on the ‘+’ next to GAME_BOARD. Click on ‘-’ to collapse it again. This will work for variables of derived type as well. The Watch Dialog can be resized by dragging its edges or corners with the mouse.

It is recommended that large arrays be kept collapsed while stepping through your program, as updating the values of the elements of large arrays while stepping is time consuming.



Changing the Values of VariablesYou can change the value of a variable in a Watch Dialog (see above) by clicking on it, then changing its value in the space below and clicking Change. Only scalar data, single elements of arrays, and single components of derived types can be changed in this way.

Reloading your ProgramTo reload your program, select Reload Program from the debug menu. All checkpoints will remain in effect.

ConfigurationThe CONFIG subdirectory under your Lahey ED Developer installation directory contains your personal configuration files which define the customizations you have made. The orig-inal versions of these files have the extension ".xxx", and your active files have the extension ".iii", where "iii" are your initials which you specified the first time ED was invoked. At installation time, if you installed the Lahey ED Developer component, and active personal configuration files were found, some of your personal configuration files may have been replaced in the CONFIG directory to ensure that you have the latest changes that were made to ED.

To change ED’s configuration select Options|Configuration or press F11. Click on the appropriate tab to display and change a configurable item. Pressing the help button while in one of the configuration dialog boxes brings up context-sensitive help on any of the features in the dialog box.

Status LineControls display of the time, date, and window bar.

DisplayControls the display of windows, control characters, menus, and toolbars.

FontsControls the type and size of the display font.

ColorsControls the colors for syntax highlighting of your source.

Session InfoControls various parameters for the way ED starts, including whether to restore the current directory, whether to save the desktop state automatically on exit, how large a cache to use, and how large a history list to keep.

BehaviorControls keyboard emulation, cursor movement and insert/replace behavior.


Configuration

SafetyControls how backup copies of your source file are kept.

LockingControls how files are locked when accessed on a LAN.


5 Command-Line Debugging with FDB

FDB is a command-line symbolic source-level debugger for Fortran 95, C, and assembly pro-grams. Use FDB if you feel more comfortable with a command-line debugger than with the WinFDB Windows debugger, or if you need access to debugging commands not available in WinFDB.

Before debugging your program you must compile it using the -g option (see”Compiler and Linker Options” on page 20). The -g option creates an additional file with debugging infor-mation -- this file has the same name as the executable with the extension .ydg. Debugging cannot be performed without the presence of the .ydg file in the same directory as the exe-cutable file. FDB cannot be used on LF90 executables.

Starting FDBTo start FDB type:

FDB exefile

Where: exefile is the name of an executable file compiled with the -g option.

CommandsCommands can be abbreviated by entering only the underlined letter or letters in the com-mand descriptions. For example, kill can be abbreviated simply k and oncebreak can be abbreviated ob. All commands should be typed in lower case, unless otherwise noted.


Chapter 5 Command-Line Debugging with FDB

Executing and Terminating a Program

run arglist

Passes the arglist list of arguments to the program at execution time. When arglist is omitted, the program is executed using the arguments last specified. If arglist contains an argument that starts with "<" or ">", the program is executed after the I/O is redirected.

Run

Executes the program without arguments. The “R” should be upper case.

kill

Forces cancellation of the program.

param commandline arglist

Assign the program’s command line argument list a new set of values

param commandline

Display the current list of command line arguments

clear commandline

The argument list is deleted

quit

Ends the debugging session.

Shell Commands

cd dir

Change working directory to dir

pwd

Display the current working directory path


Breakpoints

Breakpoints

General Syntaxbreak [location [? expr]]

Where location corresponds to an address in the program or a line number in a source file, and expr corresponds to a conditional expression associated with the breakpoint. The value of location may be specified by one of the following items:

• [’file’] line specifies line number line in the source file file. If omitted, file defaults to the current file.

• proc [+|- offset] specifies the line number corresponding to the entry point of func-tion or subroutine proc plus or minus offset lines. When using this syntax, proc may not be a module or internal procedure.

• proc@_inproc specifies internal procedure inproc within proc.• mod@_proc[@_inproc] specifies procedure proc contained in module mod or inter-

nal procedure inproc within module procedure proc.• *addr specifies a physical address (default radix is hexadecimal).• If location is omitted, it defaults to the current line of code

The conditional expression expr can be constructed of program variables, typedef elements, and constants, along with the following operators:

Minus unary operator (-)Plus unary operator (+)Assignment statement (=)Scalar relational operator (<, <=, ==, /=, >, >=, .LT., .LE., .EQ., .NE., .GT., .GE.)Logical operator (.NOT., .AND., .OR., .EQV., .NEQV.)

break [ ’file’ ] lineSets a breakpoint at the line number line in the source file file. If omitted, file defaults to the current file. Note that the “apostrophes” in ‘file‘, above, are the standard apostrophe charac-ter (ascii 39).

break [ ’file’ ] funcnameSets a breakpoint at the entry point of the function funcname in the source file file. If omitted, file defaults to the current file. Note that the “apostrophes” in ‘file‘, above, are the standard apostrophe character (ascii 39).

break *addrSets a breakpoint at address addr.

breakSets a breakpoint at the current line.



breakon [#n]Enables the breakpoint number n. If #n is omitted, all breakpoints are enabled. Note that the “#” symbol is required.

breakoff [#n]Disables, but does not remove, the breakpoint number n. If #n is omitted, all breakpoints are disabled. Note that the “#” symbol is required.

condition #n exprAssociate conditional expression expr with the breakpoint whose serial number is n. Note that the “#” symbol is required.

condition #nRemove any condition associated with the breakpoint whose serial number is n. Note that the “#” symbol is required.

oncebreakSets a temporary breakpoint that is deleted after the program is stopped at the breakpoint once. OnceBreak in other regards, including arguments, works like Break.

regularbreak "regex"Set a breakpoint at the beginning of all functions or procedures with a name matching regular expression regex.

delete locationRemoves the breakpoint at location location as described in above syntax description.

delete [ ’file’ ] lineRemoves the breakpoint for the line number line in the source file specified as file. If omitted, file defaults to the current file. Note that the “apostrophes” in ‘file‘, above, are the standard apostrophe character (ascii 39).

delete [ ’file’ ] funcnameRemoves the breakpoint for the entry point of the function funcname in the source file file. If omitted, file defaults to the current file. Note that the “apostrophes” in ‘file‘, above, are the standard apostrophe character (ascii 39).

delete *addrRemoves the breakpoint for the address addr.

delete #nRemoves breakpoint number n.


Controlling Program Execution

deleteRemoves all breakpoints.

skip #n countSkips the breakpoint number n count times.

onstop #n cmd[;cmd2;cmd3...;cmdn]Upon encountering breakpoint n, execute the specified fdb command(s).

show breakBDisplays all breakpoints. If using the abbreviation “B”, the “B” must be upper case.

Controlling Program Execution

continue [ count ]Continues program execution until a breakpoint's count reaches count. Then, execution stops. If omitted, count defaults to 1 and the execution is interrupted at the next breakpoint. Program execution is continued without the program being notified of a signal, even if the program was broken by that signal. In this case, program execution is usually interrupted later when the program is broken again at the same instruction.

silentcontinue [ count ]Same as Continue but if a signal breaks a program, the program is notified of that signal when program execution is continued.

step [ count ]Executes the next count lines, including the current line. If omitted, count defaults to 1, and only the current line is executed. If a function or subroutine call is encountered, execution “steps into” that procedure.

silentstep [ count ]Same as Step but if a signal breaks a program, the program is notified of that signal when program execution is continued.

stepi [ count ]Executes the next count machine language instructions, including the current instruction. If omitted, count defaults to 1, and only the current instruction is executed.



silentstepi [ count ]Same as Stepi but if a signal breaks a program, the program is notified of that signal when program execution is continued.

next [ count ]Executes the next count lines, including the current line, where a function or subroutine call is considered to be a line. If omitted, count defaults to 1, and only the current line is executed. In other words, if a function or subroutine call is encountered, execution “steps over” that procedure.

silentnext [ count ]Same as Next but if a signal breaks a program, the program is notified of that signal when program execution is continued.

nexti [ count ]Executes the next count machine language instructions, including the current instruction, where a function call is considered to be an instruction. If omitted, count defaults to 1, and only the current instruction is executed.

silentnexti [ count ] or nin [ count ]Same as Nexti but if a signal breaks a program, the program is notified of that signal when program execution is continued.

untilContinues program execution until reaching the next instruction or statement.

until locContinues program execution until reaching the location or line loc.

until *addrContinues program execution until reaching the address addr.

until +|-offsetContinues program execution until reaching the line forward (+) or backward (-) offset lines from the current line.

until returnContinues program execution until returning to the calling line of the function that includes the current breakpoint.


Displaying Program Stack Information

Displaying Program Stack Information

traceback [n]Displays subprogram entry points (frames) in the stack, where n is the number of stack frames to be processed from the current frame.

frame [#n]Select stack frame number n. If n is omitted, the current stack frame is selected. Note that the “#” symbol is required.

upside [n]Select the stack frame for the procedure n levels up the call chain (down the chain if n is less than 0). The default value of n is 1.

downside [n]Select the stack frame for the procedure n levels down the call chain (up the chain if n is less than 0). The default value of n is 1.

show argsDisplay argument information for the procedure corresponding to the currently selected frame

show localsDisplay local variables for the procedure corresponding to the currently selected frame

show reg [ $r ]Displays the contents of the register r in the current frame. r cannot be a floating-point reg-ister. If $r is omitted, the contents of all registers except floating-point registers are displayed. Note that the $ symbol is required.

show freg [ $fr ]Displays the contents of the floating-point register fr in the current frame. If $fr is omitted, the contents of all floating-point registers are displayed. Note that the $ symbol is required.

show regsDisplays the contents of all registers including floating-point registers in the current frame.

show mapDisplays the address map.



Setting and Displaying Program Variables

set variable = valueSets variable to value.

set *addr = valueSets *addr to value.

set reg = valueSets reg to value. reg must be a register or a floating-point register.

print [ [:F] variable [ = value ] ]Displays the content of the program variable variable by using the edit format F. If edit for-mat F is omitted, it is implied based on the type of variable. variable can be a scalar, array, array element, array section, derived type, or derived type element. F can have any of the fol-lowing values:

x hexadecimald signed decimalu unsigned decimalo octalf floating-pointc characters character stringa address of variable (use “&variable” to denote l-value)

If value is specified, the variable will be set to value.

If no arguments are specified, the last print command having arguments is repeated.

memprint [:FuN ] addr dump [:FuN ] addr Displays the content of the memory address addr by using edit format F. u indicates the dis-play unit, and N indicates the number of units. F can have the same values as were defined for the Print command variable F.

If omitted, f defaults to x (hexadecimal).

u can have any of the following values:

b one byteh two bytes (half word)w four bytes (word)l eight bytes (long word/double word)


Source File Display

If u is omitted, it defaults to w (word). If n is omitted, it defaults to 1. Therefore, the two fol-lowing commands have the same result:

memprint addrmemprint :xw1 addr

Source File Display

show sourceDisplays the name of the current file.

list nowDisplays the current line.

list [ next ]Displays the next 10 lines, including the current line. The current line is changed to the last line displayed.

list previousDisplays the last 10 lines, except for the current line. The current line is changed to the last line displayed.

list aroundDisplays the last 5 lines and the next 5 lines, including the current line. The current line is changed to the last line displayed.

list [ ’file’ ] numChanges from the current line of the current file to the line number num of the source file file, and displays the next 10 lines, including the new current line. If file is omitted, the current file is not changed.

list +|-offsetDisplays the line forward (+) or backward (-) offset lines from the current line. The current line is changed to the last line displayed.

list [ ’file’ ] top,botDisplays the source file lines between line number top and line number bot in the source file file. If file is omitted, it defaults to the current file. The current line is changed to the last line displayed.



list [ func[tion ] funcnameDisplays the last 5 lines and the next 5 lines of the entry point of the function funcname.

disasDisplays the current machine language instruction in disassembled form.

disas *addr1 [ ,*addr2 ]Displays the machine language instructions between address addr1 and address addr2 in dis-assembled form. If addr2 is omitted, it defaults to the end of the current function that contains address addr1.

disas funcnameDisplays all instructions of the function funcname in disassembled form.

Automatic Display

screen [:F] exprDisplays the value of expression expr according to format F every time the program stops.

screenDisplays the names and values of all expressions set by the screen [:F] expr command above.

unscreen [#n]Remove automatic display number n (“#” symbol required). When #n is omitted, all are removed.

screenoff [#n]Deactivate automatic display number n. When #n is omitted, all are deactivated.

screenon [#n]Activate automatic display number n. When #n is omitted, all are activated.

show screenDisplays a numbered list of all expressions set by the screen [:F] expr command above.


Symbols

Symbols

show function ["regex"]Display the type and name of all functions or subroutines with a name that matches regular expression regex. When regex is omitted, all procedure names and types are displayed.

show variable ["regex"]Display the type and name of all variables with a name that matches regular expression regex. When regex is omitted, all variable names and types are displayed.

Scripts

alias cmd "cmd-str"Assigns the fdb command(s) in cmd-str to alias cmd.

alias [cmd]show alias [cmd]

display the alias cmd definition. When cmd is omitted, all the definitions are displayed.

unalias [cmd]Remove the alias cmd definition. When cmd is omitted, all the definitions are removed.

Signals

signal sig actionBehavior action is set for signal sig. Please refer to signal(5) for the name which can be spec-ified for sig. The possible values for action are:

stopped Execution stopped when signal sig encountered

throw Execution not stopped when signal sig encountered

show signal [sig]Displays the set response for signal sig. If sig is omitted, the response for all signals is displayed.



Miscellaneous Controls

param listsize numThe number of lines displayed by the list command is set to num. The initial (default) value of num is 10.

param prompt "str"str is used as a prompt character string. The initial (default) value is “fdb*”. Note that the double quotes are required.

param printelements numSet the number of displayed array elements to num when printing arrays. The initial (default) value is 200. The minimum value of num is 10. Setting num to 0 implies no limit.

param prmDisplay the value of parameter prm.

Files

show execDisplay the name of the current executable file.

param execpath [path]Add path to the execution file search path. If path is omitted, the value of the search path is displayed. Note that this search path is comprised of a list of directories separated by semicolons.

param srcpath [path]Add path to the source file search path when searching for procedures, variables, etc. If path is omitted, the value of the search path is displayed. Note that this search path is comprised of a list of directories separated by semicolons.

show sourceDisplay the name of the current source file.

show sourcesDisplay the names of all source files in the program.


Fortran 95 Specific

Fortran 95 Specific

breakall mdlSet a breakpoint in all Fortran procedures (including internal procedures) in module mdl.

breakall funcSet a breakpoint in all internal procedures in procure func.

show ffileDisplays information about the files that are currently open in the Fortran program.

show foptDisplay the runtime options specified at the start of Fortran program execution.

Communicating with fdb

FunctionsIn a Fortran 95 program, if modules and internal subprograms are used, functions are speci-fied as the following:

A module subprogram sub defined inside a module module is specified as module@sub.

An entry point ent defined inside a module module is specified as module@ent.

An internal subprogram insub defined inside a module subprogram sub within a module mod-ule is specified as module@sub@insub.

An internal subprogram insub defined inside a subprogram sub is specified as sub@insub.

The name of the top level function, MAIN_, is not needed when specifying a function.

VariablesVariables are specified in fdb in the same manner as they are specified in Fortran 95 or C.

In C, a structure member is specified as variable.member or variable->member if variable is a pointer. In Fortran 95, a derived-type (i.e., structure) component is specified as variable%member.

In C, an array element is specified as variable[member][member].... In Fortran 95, an array element is specified as variable(member,member,...). Note that in Fortran 95, omission of array subscripts implies a reference to the entire array. Listing of array contents in Fortran 95 is limited by the printelements parameter (see ”Miscellaneous Controls” on page 114).



Values

Numeric values can be of types integer, real, unsigned octal, or unsigned hexadecimal. Val-ues of type real can have an exponent, for example 3.14e10.

In a Fortran 95 program, values of type complex, logical, and character are also allowed. Val-ues of type complex are represented as (real-part,imaginary-part). Character data is represented as " character string " (the string is delimited by quotation marks, i.e., ascii 34).

Values of type logical are represented as .t. or .f..

Addresses

Addresses can be represented as unsigned decimal numbers, unsigned octal numbers (which must start with 0), or unsigned hexadecimal numbers (which must start with 0x or 0X). The following examples show print commands with address specifications.

memprint 1024 (The content of the area addressed by 0x0400 is displayed.)

memprint 01024 (The content of the area addressed by 0x0214 is displayed.)

memprint 0x1024 (The content of the area addressed by 0x1024 is displayed.)

Registers

$BP Base Pointer

$SP Stack Pointer

$EIP Program counter

$EFLAGS Processor state register

$ST[0-7] Floating-point registers

Names

In Fortran 95 programs, a lowercase letter in the name (such as a function name, variable name, and so on) is the same as the corresponding uppercase letter. The main program name is MAIN_ and a subprogram name is generated by adding an underscore(_) after the corre-sponding name specified in the Fortran source program. A common block name is also generated by adding an underscore (_) after the corresponding name specified in the Fortran source program.


6 Windows Debugging with WinFDB

WinFDB is the Windows version of the FDB symbolic source-level debugger for Fortran 95, C, and assembly programs. While debugging, you can watch the values of variables change during program execution and set breakpoints with a mouse click. The WinFDB debugger can run your program, set breakpoints, step a line at a time, view the values of variables in your program in several different ways, and change the values of variables while running your program. The current executable line and any breakpoints are indicated with markers in the left margin of the source code display.

Before debugging your program you must compile it using the -g option (see“Compiler and Linker Options” on page 20). The -g option creates an additional file with debugging infor-mation -- this file has the same name as the executable with the extension .ydg. Debugging cannot be performed without the presence of the .ydg file in the same directory as the exe-cutable file. WinFDB cannot be used on LF90 executables.

This chapter assumes a basic familiarity with Windows. It presents an overview of Win-FDB’s functionality. More detailed information is available through WinFDB’s on-line help.

How to Start and Terminate WinFDBThere are three ways to start the WinFDB debugger:

1. From the Windows command prompt2. From the desktop icon or from the Start menu3. From the Lahey ED developer

Starting from the command promptType WINFDB followed optionally by the name of the executable file to be debugged:


Chapter 6 Windows Debugging with WinFDB

WINFDB [filename]

Unless the full path of filename is provided, WinFDB will assume it resides in the current working directory.

Starting from the Windows desktopStart the debugger by double-clicking the WinFDB icon if it is present (the desktop icon is offered as an option at installation time); otherwise use the Start | Programs... dialog.

Starting from the ED DeveloperThere are two ways of starting the WinFDB debugger while in ED. You can click on the Debug button from the toolbar, or select Tools|Debug. ED will assume the executable file has the same name as the source file in the currently active edit window.

If prompted, enter the name of the executable file, including the filename extension (.exe) and, if the file is not in ED’s current directory, a path. For example, if the executable file myprog.exe is in a directory called “programs” below the root, you would enter

\programs\myprog.exe

Terminating the DebuggerTerminate the Debugger by selecting the Exit Debugger command from the File menu in the debugger window.


Debugger Window

Debugger WindowSee the figure below.

Debugger WindowThe following items are visible in the above figure:

1. The source code display, which shows the lines of source code corresponding to the section of the program currently being executed. The left-hand margin of this display shows the line numbers of the code, along with symbols indicating the current line of execution and break-points, if any.

2. The Menu bar, used for activating all WinFDB commands.

3. The toolbar, which contains icons that activate frequently used menu commands. These commands can also be executed from the Menu Bar.

4. The status bar, which displays an explanation of each menu or toolbar command.

Status bar

Current line

Tool bar

of execution

Menu bar



Debugger Menus

File MenuThe table below lists the File Menu commands:

Program MenuThe table below lists the Program Menu commands.

Table 10: File Menu Commands

Command Name Function

Open Selects executable file to be debugged

Close Closes the chosen window (this command is only available if more than one window is being displayed)

Exit Debugger Terminates the WinFDB debugger

Table 11: Program Menu Commands


Restart Reruns the same program.

Set OptionsSpecifies the argument(s) of the program to be debugged and the runtime option(s) at execution (i.e., command-line arguments)


Debug Menu

Debug MenuThe table below lists the Debug Menu commands.

Mode MenuThe table below lists the Mode Menu commands.

Table 12: Debug Menu commands


Go Runs the program to be debugged; continues an execution that stopped due to a breakpoint, etc.

Interrupt Pauses the execution of the visual step mode.

Step InRuns the next statement. Runs up to the beginning of the function if the statement includes the function (i.e., “step into”).

Step Over Runs up to the next line, assuming the function call is one line

Kill Stops the debugging session

Breakpoints... For displaying, setting, and clearing breakpoints.

Watch... For selecting and displaying variables during execution.

Registers Displays current values of CPU registers.

Traceback Displays the traceback information

Map Displays the modules currently loaded in memory.

Input Command...Enter FDB commands for detailed debugging; the results appear in the Input Command Log window. See FDB“Com-mands” on page 103

Table 13: Mode Menu Commands

CommandName Function

Visual Step Activates the visual step mode



Window MenuThe table below lists the Window Menu commands (note - the Window menu is displayed only if one or more of the Debugger’s child windows are displayed):

View MenuThe table below lists the View Menu commands:

Help MenuThe table below lists the Help Menu commands:

Using the DebuggerThe debugger has the following functions:

Table 14: Window Menu commands


Cascade Displays all open windows so that they overlap, revealing the Title Bar for each window.

Tile Horizontally Displays debug information from left to right.

Tile Vertically Displays debug information from top to bottom.

Arrange Icons Arranges all the icons along the bottom of the win-dow.

Table 15: View Menu commands


Toolbar Specifies whether to display the toolbar.

Status Bar Specifies whether to display the status bar.

Table 16: Help Menu commands


Help Topics Displays the help topics.

About Debugger Displays version information for the debugger.


Starting the Program

• Starting the program to be debugged• Setting and deleting breakpoints• Running and stopping the program• Displaying debug information

Starting the ProgramThe first step in debugging is to ensure that the program to be debugged is loaded into the debugger. If the debugger is invoked from the command line or the ED Developer with an executable file specified, the file is loaded automatically. If the executable file is not speci-fied, follow these steps:

1. Click the Open command in the File menu to display the Open File dialog box.2. In the Open File dialog box, click or double-click the program to be debugged

(executable file).3. Click the Open button.

After you complete these steps, start debugging by clicking the Go command in the Debug menu twice; once to load the executable, and once more to begin the debug session. The source program window will open, and the finger icon will appear at the program starting point. If the main program is compiled without specifying the -g option, the source program and the finger icon are not displayed.

Setting and Deleting Breakpoints

Setting a BreakpointYou can stop program execution at any point by setting a breakpoint, allowing the status of variables and registers to be examined. A breakpoint can only be set on an executable line of code; it cannot be set at a comment or variable declaration, for example.

Start the program to be debugged and set the breakpoint when debugging enters start status. To set a breakpoint at a line, position the mouse pointer on the line number in the source pro-gram and click the left mouse button.

A breakpoint can also be set as follows:

1. Select the Breakpoints command from the Debug menu to display the Breakpoints dia-log box (see the figure below).

2. In the ‘Line:’ field in the Breakpoints dialog box, specify the line number for which the breakpoint is to be set.

3. Click the Add button.

4. Check that the line number appears in the breakpoint list; then click the OK button.



5. The above step displays the breakpoint (flag) in the displayed source program. To set the breakpoint for another line number, repeat steps (2) and (3).

Releasing the BreakpointSome or all breakpoints that have been set can be deleted.

To delete a breakpoint at a line, position the pointer on the line number in the source program (indicated with a flag) and click the left button.

A breakpoint can also be deleted as follows:

1. Select the Breakpoints command from the Debug menu to display the Breakpoints dialog box.

2. In the Breakpoints List field in the Breakpoints dialog box, click the line number to be deleted.

3. Click the Delete button, then the OK button.

All breakpoints can be deleted as follows:

1. Select the Breakpoints command from the Debug menu to display the Breakpoints dialog box.

2. Click the Clear button in the Breakpoints dialog box, then click the OK button.


Running and Stopping the Program

Running and Stopping the Program

Running the ProgramTo run the program until the first (or next) breakpoint, select the Go command from the Debug menu. To step one line, entering a function call if present, select the Step In com-mand from the Debug menu. To step one line and treat a function call as one instruction, select the Step Over command from the Debug menu.

You can execute the program in “Visual Step Mode” by using the Visual Step command in the Mode menu. Visual Step Mode allows you to run the program “slow motion”, seeing each step as it is executed, and it works as follows:

When you select the Go command from the Debug menu in the visual step mode, the finger icon moves line by line as the program is executed. This provides a means of visually check-ing the program execution sequence. To pause the execution in the visual step mode, select the Interrupt command from the Debug menu.

Stopping the ProgramTo stop the program, select the Kill command from the Debug menu. The “debugging enabled” status is released.

To restart debugging, see below.

Rerunning the ProgramTo restart debugging, reload the program by selecting the Restart command from the Pro-gram menu.

Then, start the program by selecting the Go command from the Debug menu.

Displaying Debug InformationThe debugger can display the following debug information:

• Variables• Registers• Traceback• Load map• Output

The displayed debug information is updated at the following times:

• When a step run or line run is executed.• When a program is stopped at a breakpoint.• When a program running in the visual step mode is paused.

The display method for each type of debug information is listed below.



Displaying VariablesDo the following to display the contents of variables:

1. Select the Watch command from the Debug menu to display the Watch dialog box (see the figure below).

2. In the Variable field, specify the variable to be displayed.3. Click the Add button. The specified variable is then registered in the variable field.

When the program is executed, the current variable contents are displayed on the right-hand side of the “=” symbol.

Variable contents are not displayed when any of the following is true:

• The program to be debugged has not been started.• The local variable of another function or subroutine was specified.• A non used variable was specified.

To delete the registered variable, do one of the following:

1. In the Variable field, specify the variable name to be deleted and click the Delete button.

2. Click the registered variable, then click the Delete button. If you click the Delete but-ton without clicking a variable, the first variable in the variable field is deleted.

To delete all the variables registered in the variable field, click the Clear button.

Displaying RegistersDo the following to display the register contents:

1. Select the Registers command from the Debug menu.


Displaying a Traceback

The current register contents are displayed in the Registers window (see the figure below).

Displaying a TracebackDo the following to display a traceback:

1. Select the Traceback command from the Debug menu.

The current traceback information is displayed in the Traceback window (see the figure below).

Displaying a Load MapDo the following to display a load map:

1. Select the Map command from the Debug menu.



The current loaded modules are displayed in the Map window (see the figure below).

Entering FDB CommandsDo the following to enter FDB commands for more detailed debugging activity:

1. Select the “Input Command” command from the Debug menu.2. Type a command in the “Command” field in the “Input Command” dialog, or select

a command from the drop-down command history, or simply click OK to repeat the last command (see FDB “Commands” on page 103).


Restrictions

The messages and results are displayed in the Input Command Log window (see the figure below).

Restrictions1. The Debugger will not debug a program that has been compiled by another vendor’s com-piler, even if their debug option is specified. Other vendor’s debuggers will not debug a program that has been compiled by LF95, even if the debug option (-g) is specified.

2. The Debugger will not debug those parts of a statically linked mixed language program which were not compiled with LF95 or FCC.

3. An adjustable array that is a dummy argument cannot be debugged if it appears at the beginning of a procedure or a function.

Example:line number

1 subroutine sub(x,y,i)2 real x(5:i)

3 real y(i+3)

In this example, adjustable arrays x and y cannot be debugged where the beginning of the procedure is sub(line number 1).

4. The dummy argument of a main entry cannot be debugged at the sub entry.



Example:subroutine sub(a,b) : :entry ent(b)

In this example, the dummy argument a, which is in the main entry’s argument list but not in the sub entry ent, cannot be debugged. However, the dummy argument b, which is passed to the sub entry ent, can be debugged.

5. A breakpoint cannot be set for an executable statement in an include file.

6. An array of an assumed size can be debugged only for the lower boundary.

7. A label cannot be debugged.

8. In include files that contain expressions or a #line statement, the C programs cannot be debugged.

9. When in a Fortran program the continue statement has no instruction, the breakpoint is automatically set at the next statement.

Example:line number1 integer i2 :3 assign 10 to i4 10 continue5 i=1

In the above example, if you set a breakpoint at line 4, the breakpoint is actually set at line 5.

10. If a Fortran program has a contains statement, the breakpoint cannot be set at its end statement.

11. If the result of a function is one of the following, the step and next commands have no effect:

- array- derived type- pointer- character whose length is not a constant

12. Allocatable or pointer arrays that are globally declared or globally used cannot be debugged within the module they are declared or used in. Global allocatable or pointer arrays may be debugged if they are locally used.

13. If a pointer variable is a common element, the pointer variable cannot be debugged.

Example:common /com/ppointer (p,j)


Other Remarks

The above variable j cannot be debugged.

14. A dummy argument declared with the entry statement in a procedure cannot be debugged except for the first element of the explicit-shape array and the top of the assumed type param-eter string (including the pointervariable).

Example:subroutine s1(a,i,c)real a(i)character*(*) c :entry ent(b,j,d)

The above cannot be debugged except a(1) and c(1:1).

15. When debugging a program using the VSW function, please note that Execution should be used to restart the execution after returning from the call-back procedure. If Step or Line is used to restart the execution, breakpoints may not be ignored.

Other Remarks1. In source level debugging, the executable file (.EXE) and its debugging information file (.YDG) must exist in the same directory. In the same way, the dynamic link library (.DLL) and its debugging information file must exist in the same directory.

2. In source level debugging, the prolog instructions of each function may cause the follow-ing features not to work correctly:

- traceback indication- next command

3. When searching the source files, the Debugger refers to the environment variable FDB_SRC_PATH. There are two ways of specifying the environment variable:

Example 1: In the command promptc:\> set FDB_SRC_PATH=c:\users\fujitsu\prog;d:\common\lib\srcc:\> winfdb

The above specifies the full pathnames of the directory in which the source files exist. If there are more than two directories, you may specify them with the separator ";". Then, invoke the Debugger.

Example 2: In the Control Panel (Windows NT only) Variable(V): FDB_SRC_PATH Value(A): c:\users\fujitsu\prog;d:\common\lib\src

The above specifies environment variable FDB_SRC_PATH to each user’s environment variable of the System in the Control Panel. In Windows 95/98, specify the environment vari-able FDB_SRC_PATH in AUTOEXEC.BAT.



4. If the debug option is specified when linking, object filenames must be specified with full pathnames except for the objects in the current directory.

5. If objects are linked with the debug option and static link libraries are in a different direc-tory from the object files and debugging information files(.YDG), to debug the executable file, specify the full path-names of the object files and the debugging information file to the environment variable FDB_MERG_PATH.

Example: Specify the environment variable FDB_MERG_PATHset FDB_MERG_PATH=c:\users\fujitsu;e:\apl\users\lib\obj

In the above, the directory name is specified with full pathnames separated by a semicolon.

Note: The object file and debugging information file are searched as follows:

1. The directories specified in the environment variable FDB_MERG_PATH.

2. The directories which store the user’s library.


7 Library Manager

The Microsoft librarian utility, LIB, can be used to manage library creation and modification, extract object files from an existing library, or create import libraries. These three tasks are mutually exclusive, which means that LIB can only be invoked to perform one of these func-tions at a time.

By default, LIB outputs a file using the name of the first object or library file that is encoun-tered, giving it the .lib extension. If a file with this name already exists, it is overwritten. The default action can be overridden by using the /out:libname option.

LIB accepts both OMF and COFF format object files. When an OMF object file is specified, LIB changes the format to COFF before creating a library.

LIB Syntax:LIB [options] [files]

options is a list of options separated by spaces. Options begin with a hyphen (-) or a slash(/). They may appear in any order and are processed in the order they are encountered. Arguments to options are denoted by a colon character (:), and there cannot be any spaces or tabs between an option and it’s argument.

files is a space separated list of object and library filenames.

Options

/CONVERTConverts an import library to Visual Studio version 5 format.


Chapter 7 Library Manager

/DEF[:filename]Indicates that an import library is to be created. filename indicates the name of a definition file. LIB will export procedures that are specified in the EXPORT section a definition file or that are specified using the /EXPORT option.

/EXPORT:symbolUsed to specify procedures to be exported when creating an import library.

/EXTRACT:membernameUsed to extract the object file membername from a library.

/INCLUDE:symbolAdds symbol to the symbol table when creating an import library.

/LIBPATH:dirSets a path to be searched for library files. This path overrides a path specified by the LIB environment variable.

/LINK50COMPATGenerates an import library using Visual Studio version 5 format.

/LIST[:filename]Displays a list of objects in the first library file encountered. If filename is absent, the output is displayed on stdout. If filename is present, the output is directed to the specified file.

/NODEFAULTLIB[:library]Do not refer to default libraries when resolving external references. If library is present, only the specified library is removed from the default library list.

/NOLOGOSuppresses the display of the version and copyright banner.

/OUT:libnameSets the name of the output library file.

/REMOVE:membernameRemoves the object file named membername from the specified library.

/VERBOSEDisplays detailed information about the progress of the LIB session.


Response Files

Response FilesIt is possible to place commonly used or long LIB command-line parameters in a response file. LIB command-line parameters are entered in a response file in the same manner as they would be entered on the command line. A new line in a response file is treated like a sepa-rator on the LIB command line.

To invoke the response file, type:

LIB @response-filename

where response-filename is the name of the response file with extension.

Creating and maintaining COFF librariesThe default usage for LIB is to perform library management. LIB runs in default mode when-ever the /def or /extract options are not used. LIB will accept any object files and libraries specified on the command line and in a command file, and create a library containing the combined contents of the input files.

Example 1:lib obj1.obj obj2.obj lib1.lib

In this example, the files obj1.obj obj2.obj and lib1.lib are combined into a library called obj1.lib. If obj1.lib did not exist before this command was invoked, it is cre-ated. If obj1.lib did exist before this command was invoked, it’s previous contents are overwritten.

Example 2:lib obj1.obj obj2.obj lib1.lib /out:mylib.lib

In this example, the files obj1.obj obj2.obj and lib1.lib are combined into a library called mylib.lib. If mylib.lib did not exist before this command was invoked, it is created. If mylib.lib did exist before this command was invoked, it’s previous contents are overwritten.

Example 3:lib /remove:obj1.obj mylib.lib

In this example, the object file obj1.obj is removed from the library mylib.lib.

Example 4:lib mylib.lib obj1.obj

In this example, the object file obj1.obj is added to the library mylib.lib.



Extracting object files from librariesWhen the /extract option is used, LIB extracts an object file from an existing library. The object being extracted is not removed from the library. To delete an object from a library use the /remove option.

Example:lib /extract:obj1.obj mylib.lib

In this example, the object file obj1.obj is extracted from the library mylib.lib and is written to disk. If a file named obj1.obj previously existed, it is overwritten.

Creating import librariesWhen the /def option is specified, LIB is used to generate an import library. It is usually not necessary to use LIB to create an import library, because the import library is automati-cally generated by LINK whenever a DLL is created. If the user is creating a DLL with a 3rd party language system and an import library is not created, or if the user is provided with a DLL by a 3rd party without an import library, one can be generated using LIB /def. For more information on creating import libraries for mixed language applications, see “Building Import Libraries” on page 47.

Two items are needed to generate an import library - a set of definitions and an object file containing the exported procedures.

Definitions may be in the form of a definition file or as arguments to the /EXPORT option. A definition file contains exported symbols as they appear in the DLL. These symbols can be listed using DUMPBIN /EXPORTS. Alternatively, a definition file can be generated from a DLL using the MAKEDEF utility. Note that the definition file that is used when creating the import library should only contain procedure names that appear in the object file, otherwise unresolved references will occur when the LIB command is executed.

If the object file that was used to create the DLL is available, an import library can easily be created using the object file and a definition file.

Example:lib /def:mydll.def dllobj.obj /out:mydll.lib

In this example the file mydll.def contains an EXPORTS header, under which export sym-bols are listed as they appear when displayed with the DUMPBIN utility. The file dllobj.obj is the object file that was linked to make the DLL.

If no object file is available, a Fortran object file can be created from a Fortran ‘stub’. All that is required is that the user know the calling sequence for the DLL procedure. A stub pro-cedure consists of a SUBROUTINE or FUNCTION statement, an argument list, declarations for any dummy arguments, a DLL_EXPORT statement, and an END statement. Note that the stub procedure name appearing in the DLL_EXPORT statement is case-sensitive, and should


Creating import libraries

have the same case as the procedure exported from the DLL. The stub procedure is compiled into an object file using the -c and an appropriate -ml option. This object file can then be used by LIB to create the import library. When compiling the LF95 program that will call the DLL, make sure that the same -ml option is used as for the stub procedure. Note that -ml lf95 is not a valid option when making an import library.

Example stub procedure (called dllsub1.f90):subroutine dllsub1(a,i,l) dllexport :: dllsub1 real :: a integer :: i logical :: lend subroutine

Example definition file (called dllsub1.def):EXPORTSdllsub1

Example compile command:lf95 -c -ml msvc dllsub1.f90

Example LIB command:lib /def:dllsub1.def dllsub1.obj /out:mydll.lib

The above examples show how to create an import library from a Fortran stub for a DLL called mydll.dll, which contains a procedure called dllsub1 having three arguments. When compiling the LF95 main program which calls mydll.dll, the -ml msvc option must be used.

Note that depending on which target is specified when using the -ml option, LIB may gen-erate a warning about multiply defined symbols. This warning can generally be disregarded.

Further examples of creating import libraries using /def and stub procedures exist in direc-tories under the EXAMPLES\MIX_LANG directory.


8 Make Utilities

Two separate make utilities are provided, Polyhedron’s AUTOMAKE and Microsoft’s NMAKE.

AUTOMAKE is an easy to use utility that enables the user to quickly and efficiently generate a Fortran application. AUTOMAKE is best used when all source files comprising an appli-cation exist in a single directory, and that directory contains no extraneous Fortran source files. Under the control of a simple configuration file, AUTOMAKE automatically scans the source files, accurately tracks file dependencies, and builds target files.

NMAKE is a traditional make utility that can be used to create complex or mixed-language applications. NMAKE is best used for building complex multiple target applications. It is the user’s responsibility to create the makefile used by NMAKE, and to ensure that files are compiled in the proper order. Although makefile contents are briefly described in this man-ual, for a more complete description of NMAKE, the user is referred to Microsoft’s MSDN website at:

http://msdn.microsoft.com

Once at this site, search on “nmake reference” and follow the links to the NMAKE documen-tation pages.

Automake

OverviewAUTOMAKE is a simple-to-use tool for re-building a program after you have made changes to Fortran and/or C source code. It examines the creation times of all the source, object and module files, and recompiles wherever it finds that an object or module file is non existent, empty or out of date. In doing this, it takes account not only of changes or additions to the source code files, but also changes or additions to MODULEs and INCLUDEd files - even when nested. For example, if you change a file which is INCLUDEd in half a dozen source


Chapter 8 Make Utilities

files, AUTOMAKE ensures that these files are re-compiled. In the case of Fortran 95, AUTOMAKE ensures that modules are recompiled from the bottom up, taking full account of module dependencies.

By default, AUTOMAKE is run by a batch file called AM.BAT. This batch file executes AUTOMAKE.EXE, which inspects a configuration file and a dependency file, scans for out of date targets, and generates a temporary batch file called AMTEMP.BAT, which contains the commands needed to bring the target up to date. Once AUTOMAKE.EXE is complete, AM.BAT executes AMTEMP.BAT to build the target, and then deletes the temporary batch file.

AUTOMAKE stores details of any dependencies in your program in a dependency file, usu-ally called 'automake.dep'. AUTOMAKE uses this data to deduce which files need to be compiled when you make a change. Unlike NMAKE utilities, which require the user to spec-ify dependencies explicitly, AUTOMAKE creates and maintains this data itself. To do this, AUTOMAKE periodically scans source files to look for INCLUDE and USE statements. This is a very fast process, which adds very little to the overall time taken to complete the update.

The operation of AUTOMAKE is controlled by a configuration file which contains the default compiler name and options, INCLUDE file search rule, etc. For simple situations, where the source code to be compiled is in a single directory, and builds into a single execut-able, it will probably be possible to use the system default configuration file, called 'automake.fig' located in LF95’s bin directory. In that case there is no need for any cus-tomization of AUTOMAKE— just type 'am' to update both your program and the dependency file.

In other cases, you may wish to change the default compiler name or options, add a special link command, or change the INCLUDE file search rule; this can be achieved by customizing a local copy of the AUTOMAKE configuration file. More complex systems, perhaps involv-ing source code spread across several directories, can also be handled in this way.

Running AUTOMAKETo run AUTOMAKE, simply type 'am'. If there is a configuration file (AUTOMAKE.FIG) in the current directory, AUTOMAKE reads it. Otherwise, it starts the AUTOMAKE Config-uration file editor, AMEDIT.EXE.

The AUTOMAKE Configuration File EditorThe AUTOMAKE Configuration File Editor (AMEDIT) is a Windows-based utility for cre-ating and maintaining configuration files for use by AUTOMAKE. You can start it from a Windows 95 or NT command prompt by typing

amedit

to create a new file, or

amedit myproject.fig


The AUTOMAKE Configuration File Editor

to edit an existing one. AMEDIT is also started automatically when AUTOMAKE first runs in a directory with no AUTOMAKE.FIG file.

If you are creating a new file, the editor first presents a dialog containing a set of options suit-able for most simple projects. The defaults are:

• to use LF95 with options set for debugging. You can select other options, including LF95 with options set for optimization, from the drop-down list.

• to compile all files fitting *.f90 in the current directory. This can be changed, for example to *.for, by typing in the second box.

• to create an executable file called target.exe. This can be changed by typing in the third box, or by using the file selection dialog (click on the button at the right of the box).

When you are finished, click “OK” to create the file.

If your project is more complicated than that—for example if you have files in more than one directory, or you need special linker instructions—click on the “Editor” button and a new dia-log with many more possibilities is displayed.



The pane on the left-hand side lists the sections in the AUTOMAKE.FIG file. When you click on the section in the left-hand pane, details appear in the right-hand pane. Typically there is a general section, which specifies options, such as debug options, which relate to the entire process. One or more compilation sections follow this, each specifying a set of files to be compiled together with the compiler options. Finally, there is usually a link section, in which the link command is specified.

The link section, shown above, allows you to enter the executable file name and the link com-mand (see ”LINK=” on page 147 for an explanation of place markers such as %rf and %ex). There is a drop-down list of linker options which, once selected, can be added to the link com-mand by clicking on the ‘+’ button. Finally, you can add comments as required in the box at the bottom of the right-hand pane.

Compilation sections are similar to link sections, but with a few more options:


The AUTOMAKE Configuration File Editor

This time you must specify the files to be compiled (see ”FILES=” on page 145) and the compile command (see ”COMPILE=” on page 145). As in the LINK section, there is a drop-down list of compiler options that can be appended to the compile command by clicking on the ‘+’ button.

The other entries are all optional. They are:

• The directories to be searched for INCLUDE files (see ”INCLUDE=” on page 148)• The target directory for object files (see ”OBJDIR=” on page 148)• The object file extension (see ”OBJEXT=” on page 148)• The target directory for .MOD files (see ”MODULE=” on page 149)• Comments

New compilation sections can be added by clicking on “Add Compilation”, and deleted by clicking on “Delete Phase”. The order of compilation sections can be changed using the arrow buttons at the bottom left.

The General Section includes three check boxes:



• To specify whether AUTOMAKE should continue after a compilation error (see ”QUITONERROR” on page 149 and ”NOQUITONERROR” on page 149).

• To specify whether debugging data should be written to a file called AUTOMAKE.DBG (see ”DEBUG” on page 149).

• To specify whether a simple make file called AUTOMAKE.MAK should be written as an aid to debugging (see ”MAKEMAKE” on page 149).

The Advanced button gives access to options that are not relevant for LF95.

The AUTOMAKE Configuration FileThe AUTOMAKE configuration file is used to specify the compile and link procedures, and other details required by AUTOMAKE. It consists of a series of records of the form

keyword=value

or

keyword


The AUTOMAKE Configuration File

where keyword is an alphanumeric keyword name, and value is the string of characters assigned to the keyword. The keyword name may be preceded by spaces if required. Any record with a '#', '!' or '*' as the first non blank character is treated as a comment.

The keywords which may be inserted in the configuration file are:

LF95

Equivalent to specifying the default LF95 compile and link commands.

COMPILE=@lf95 -c %fi -mod %mo

LINK=@lf95 %ob -out %ex -mod %mo

The LF95 keyword should appear in any automake.fig file that is to be used with LF95.

FILES=

Specifies the names of files which are candidates for re-compilation. The value field should contain a single filename optionally including wild-cards. For example,

FILES=*.f90

You can also have multiple FILES= specifications, separated by AND keywords.

FILES=F90\*.F90

AND

FILES=F77\*.FOR

AND

...

Note that, with each new FILES= line. the default COMPILE= is used, unless a new COM-PILE= value is specified after the FILES= line and before AND.

Note also that, if multiple FILES= lines are specified, then the %RF place marker cannot be used in any COMPILE= lines.

COMPILE=

Specifies the command to be used to compile a source file. The command may contain place markers, which are expanded as necessary before the command is executed. For example,

COMPILE=@lf95 -c %fi

The string '%fi' in the above example is a place marker, which expands to the full name of the file to be compiled. The following table is a complete list of place markers and their meanings:



COMPILE=@lf95 -c %fi -mod %moCOMPILE=@lf95 -c @%rf -I %id

It is possible to invoke the compiler using a command file (batch file, shell script etc.). How-ever, on PCs, it is necessary to preface the batch file name with 'CALL' or 'COMMAND/C'. For example

COMPILE=CALL fcomp %fi

Note that with LF95 the -c option should always be used in a COMPILE= line.

Table 17: COMPILE= Place Markers

Place Marker Meaning

%SD expands to the name of the directory containing the source file - including a trailing '\'.

%SF expands to the source file name, excluding the directory and exten-sion.

%SE expands to the source file extension—including a leading '.'. For example is the file to be compiled is 'f:\source\main.for', %SD expands to 'f:\source\', %SF to 'main', and %SE to '.for'.

%OD expands to the name of the directory containing object code, as spec-ified using the OBJDIR= command (see below), including a trailing '\'.

%OE expands to the object file extension, as specified using the OBJEXT= command (see below), including a leading '.'.

%ID expands to the INCLUDE file search list (as specified using INCLUDE= (see below))

%MO expands to the name of directory containing modules (as specified using MODULE= (see below))

%RF expands to the name of a response file, created by AUTOMAKE, containing a list of source files. If %RF is present, the compiler is invoked only once.

%FI is equivalent to %SD%SF%SE



TARGET=Specifies the name of the program or library file which is to be built from the object code. Note that you will also have to tell the linker the name of the target file. You can do this using a %EX place marker (which expands to the file name specified using TARGET=).

TARGET=f:\execs\MYPROG.EXE

If there is no TARGET= keyword, AUTOMAKE will update the program object code, but will not attempt to re-link.

LINK=Specifies a command which may be used to update the program or library file once the object code is up to date:

LINK=@lf95 %ob -out %ex -mod %mo'

LINK=@lf95 %od*%oe -out %ex -mod %mo'

LINK=@lf95 %rf -out %ex -mod %mo'

You could use a batch file called 'l.bat' by specifying

LINK=CALL L

The following place markers are allowed in the command specified using LINK=.

Table 18: LINK= Place Markers

Place Marker Meaning

%OD expands to the name of the directory containing object code, speci-fied using the OBJDIR= command, including a trailing '\'.

%OE expands to the object file extension, as specified using the OBJEXT= command, including a leading '.'.

%OB expands to a list of object files corresponding to source files speci-fied using all FILES= commands.

%EX expands to the executable file name, as specified using TARGET=.

%MO expands to the name of directory containing modules (as specified using MODULE= )

%RF expands to the name of a response file, created by AUTOMAKE, containing a list of object files.

%LI expands to a list of all library files specified using LIBRARY=

%LLexpands to the name of a response file, created by AUTOMAKE, containing a list of library files (specified using LIBRARY=).



INCLUDE= May be used to specify the INCLUDE file search list. If no path is specified for an INCLUDEd file, AUTOMAKE looks first in the directory which contains the source file, and after that, in the directories specified using this keyword. The directory names must be sep-arated by semi-colons. For example, on a PC, we might have:

INCLUDE=C:\include;C:\include\sys

Note that the compiler will also have to be told where to look for INCLUDEd files. You can do this using a %ID place marker (which expands to the list of directories specified using INCLUDE).

SYSINCLUDE=May be used to specify the search list for system INCLUDE files (i.e. any enclosed in angled brackets), as in

#include <stat.h>

If no path is specified, AUTOMAKE looks in the directories specified using this keyword. It does not look in the current directory for system INCLUDE files unless explicitly instructed to. The directory names following SYSINCLUDE= must be separated by semi-colons.

OBJDIR=May be used to specify the name of the directory in which object files are stored. For example,

OBJDIR=OBJ\

The trailing '\' is optional. If OBJDIR= is not specified, AUTOMAKE assumes that source and object files are in the same directory. Note that if source and object files are not in the same directory, the compiler will also have to be told where to put object files. You can do this using a %OD place marker (which expands to the directory specified using OBJDIR).

OBJEXT=May be used to specify a non standard object file extension. For example to specify that object files have the extension '.abc', specify

OBJEXT=ABC

This option may be useful for dealing with unusual compilers, but more commonly to allow AUTOMAKE to deal with processes other than compilation (for example, you could use AUTOMAKE to ensure that all altered source files are run through a pre-processor prior to compilation).

KEEPOBJDIRSpecifies that the value specified using the OBJDIR= keyword should retain its value until it is explicitly reset. By default the object directory is reset at the start of each compilation phase (i.e. after an AND) to the directory containing the source files. KEEPOBJDIR should be used if object files are in a single directory which is not the same as the source directory.



LIBRARY=May be used to specify the path name of a library which will be linked into the target file. AUTOMAKE checks the modification time of the library, and forces a re-link if it was cre-ated after the target file. Each library must be specified using a separate LIBRARY= keyword.

LIBRARY=Q:\libs\math02.lib

LIBRARY=Q:\libs\graphin.lib

Note that LIBRARY= tells AUTOMAKE about the dependency, but the linker must also be told. In general, the library names must be specified in the LINK= command. You can do this explictily, or avoid re-typing the names by using a %LI or %LL place marker (see LINK= above).

MODULE=May be used to specify the name of the directory in which module files are stored.

MODULE=MODS\

The trailing '\' is optional. If MODULE= is not specified, AUTOMAKE assumes that source and module files are in the same directory. Note that if source and module files are not in the same directory, the compiler will also have to be told where to put module files. You can do this using a %MO place marker (which expands to the directory specified using MODULE=).

DEP=May be used to over-ride the default dependency file name.

DEP=THISPROG.DEP

causes AUTOMAKE to store dependency data in 'thisprog.dep' instead of 'automake.dep'.

QUITONERRORSpecifies that AUTOMAKE should halt immediately if there is a compilation error.

NOQUITONERRORSpecifies that AUTOMAKE should not halt if there is a compilation error.

MAKEMAKESpecifies that AUTOMAKE should create a text file called AUTOMAKE.MAK containing dependency information.

DEBUGCauses AUTOMAKE to write debugging information to a file called AUTOMAKE.DBG.

SCANONLYSpecifies that files in the current section (i.e. since the previous AND) may be scanned, but not compiled. This may cause files in other sections to be re-compiled. For example, a Fortran 95 module in the current section may be USEd by a file in another section, and the latter may be re-compiled when the module is changed.



COMPILEONLY

Specifies that files in the current section (i.e. since the previous AND) may be compiled if needed, but should not be included in the list of object files (generated using %RF in the LINK= command) to be linked. This may be useful if the files are part of a library.

LATESCAN

Delays scanning of source files until the last possible moment, and can, in some cases, remove the need for some scans. However this option is NOT compatible with Fortran 90 modules.

CHECK=

May be used to specify a command to be inserted after each compilation. A typical applica-tion would be to check for compilation errors. For example, under MS-DOS:

CHECK=IF ERRORLEVEL 2 GOTO QUIT

would cause the update procedure to abort if there is a compilation error.

$INSERT=

specifies that further directives should be read from the specified file. AUTOMAKE returns to read the remainder of the current file after the end of the inserted file.

$INSERT=Q:\prog1\standard.fig

An inserted file may itself contain a $INSERT= keyword, but further nesting is not allowed.

Multi-Phase CompilationSometimes, more than one compilation phase is required. For example, if source files are stored in more than one directory, you will need a separate compilation phase for each direc-tory. Multiple phases are also required if you have mixed C and Fortran source, or if you need special compilation options for particular source files.

The 'AND' keyword may be inserted in your configuration file to add a new compilation phase. You can reset the values of FILES=, COMPILE=, INCLUDE=, OBJDIR=, OBJEXT= and MOD-ULE= for each phase. All default to the value used in the previous phase, except that OBJDIR= defaults to the new source directory.

The following example shows how this feature might be used with the LF95 compiler. The same principles apply to other compilers and other platforms.


Automake Notes

# Example Configuration file for Multi-Phase

# Compilation# Compilation 1 - files in current directory

LF95

INCLUDE=\include

FILES=*.f90OBJDIR=obj

COMPILE=@lf95 -c %fi -i %id -o %od%sf%oe -tp -o1

AND

# Compilation 2 - files in utils\# INCLUDE= defaults to previous value (\include)

# if OBJDIR= were not set, it would default to utils (NOT obj)

FILES=utils\*.f90

OBJDIR=utils\objCOMPILE=@lf95 -c %fi -i %id -o %od%sf%oe -sav -chk

# Relink

TARGET=current.exe

LINK=@lf95 %ob -out %ex

Automake Notes• As AUTOMAKE executes, it issues brief messages to explain the reasons for all

compilations. It also indicates when it is scanning through a file to look for INCLUDE statements.

• If for any reason the dependency file is deleted, AUTOMAKE will create a new one. Execution of the first AUTOMAKE will be slower than usual, because of the need to regenerate the dependency data.

• AUTOMAKE recognizes the INCLUDE statements in all common variants of For-tran and C, and can be used with both languages.

• When AUTOMAKE scans source code to see if it contains INCLUDE statements, it recognizes the following generalized format:Optional spaces at the beginning of the line followed by..An optional compiler control character, '%', '$' or '#', followed by..The word INCLUDE (case insensitive) followed by..An optional colon followed by..The file name, optionally enclosed between apostrophes, quotes or angled brackets. If the file name is enclosed in angled brackets, it is assumed to be in one of the direc-tories specified using the SYSINCLUDE keyword. Otherwise, AUTOMAKE looks in the source file directory, and if it is not there, in the directories specified using the INCLUDE keyword.

• If AUTOMAKE cannot find an INCLUDE file, it reports the fact to the screen and ignores the dependency relationship.



• AUTOMAKE is invoked using a batch file called AM.BAT. There is seldom any rea-son to modify the command file, though it is very simple to do so if required. It consists of two (or three) operations:Execute AUTOMAKE. AUTOMAKE determines what needs to be done in order to update the system, and writes a batch file to do it. The options which may be appended to the AUTOMAKE command are:TO= specifies the name of the output command file created by AUTOMAKE.FIG= specifies the name of the AUTOMAKE configuration file.Execute the command file created by AUTOMAKE.Delete the command file created by AUTOMAKE. This step is, of course, optional.

NMAKE

OverviewMicrosoft’s NMAKE is a make tool that operates in the traditional manner. The user creates a makefile that specifies a list of targets and dependencies, and defines commands which are executed to build the targets. By default, NMAKE looks for a file called “Makefile”, and uses it to build any out of date targets which it defines. Unlike AUTOMAKE, NMAKE is able to build multiple targets using a single makefile.

Command line optionsWhen NMAKE is invoked, one of the following command line options may be used:

Table 19: NMAKE command line options

Option Description

/A Force build of all related targets, even when dependents are not out of date.

/B Force build of related targets when timestamps are equal.

/C Suppress copyright and other default screen output.

/D Display timestamps for each dependent file. Show message if target file does not exist.

/E Environment variables override macro definitions.


Description blocks

When NMAKE is invoked, in addition to the command line options, a target name may be supplied on the command line, and only that target and it’s dependents will be built.

Description blocksTargets, dependencies and commands are specified in a description block. A description block has the following format:

/F filenameSpecify filename as a makefile. Use a filename of ‘-’

(minus sign) to input the makefile from stdin. Terminate input with a ctrl-Z character or F6 key.

/HELP or /? Print NMAKE synopsis.

/I Ignore error codes originating from NMAKE commands.

/K Continue building unrelated dependencies if an NMAKE command returns an error code.

/N Display commands, but do not execute them. Preprocessor commands are executed.

/NOLOGO Suppress copyright message.

/P Display macro definitions, inference rules, and targets, then run the build.

/Q Check timestamps without running the build. NMAKE returns an exit code of zero if all targets are up to date.

/R Ignore predefined inference rules and predefined macros.

/S Silent mode.

/T Update timestamps of target without executing build.

/X filename Send error output to filename instead of stderr. If filename is ‘-’ (minus sign) error output is sent to stdout.

Table 19: NMAKE command line options

Option Description



target : dependency dependency ... ; commandcommands

Where:target is the file that is produced when the specified command is executed. The modification date of the target is checked against the modification date of the dependency, and if a depen-dency is newer than target, the command is executed to update target.

dependency is a tab or space separated list of files that are used to generate target. A depen-dency may appear as a target in a different description block. A dependency may contain wildcard characters. Targets and dependencies are separated by a colon (:) character. If the list of targets and dependencies extends to more than a single line, it is continued using the backslash (\) character.

commands is a block of statements that are executed to build target. If a command appears on the dependency line, it is separated with a semicolon (;) character. Otherwise, commands appear on the line immediately after the dependency line. A block of commands is termi-nated by a blank line which contains no space or tab characters. A command line that contains only space or tab characters is treated as a null command.

Substitution macrosPredefined MacrosVarious target and dependency names can be specified in a command by using a substitution macro. Macros always begin with the dollar sign ($) character. The following macros may be used in the described circumstances:

Table 20: Substitution Macros

Macro Interpretation

$@ The full name of the current target, including the path, filename, and extension.

$$@ The full name of the current target, including the path, file-name, and extension. For use only as a dependency.

$* The name of the current target, including the path and file-name, minus the extension.

$** All dependents of the current target.

$? All out-of-date dependents.

$< All out-of-date dependents. For use only in inference rules.


Suffixes

User-defined MacrosA user-defined macro is simply a variable name equated to a command or list. For example the following macro might define a set of options to a Fortran compiler:

FFLAGS = -ndal -ntrace -o1

The macro is used by preceding it with a dollar sign and enclosing it in parentheses. For example, a makefile compile command using the defined options might look like this:

lf95 $(FFLAGS) $*

Similarly, a list of source or object files can be defined with a macro:

SRCS = a.f90 b.f90 c.f90 d.f90

Once the list is defined, it can be used as a dependency, and out of date parts of the list can be referenced using a predefined macro.

SuffixesNMAKE recognizes several file suffixes, and associates predefined commands to build a file that has a familiar suffix. Because these predefinitions can interfere with the correct opera-tion of NMAKE and LF95, it is sometimes necessary to turn off the predefined build rules. This is done with the SUFFIXES directive. At the beginning of your makefile use the fol-lowing directive to disable predefined suffix build rules:

.SUFFIXES:

Once you have done this, it is necessary to define build commands by specifying suffix build rules, or by supplying a build command with each description block.

Suffix build rulesA default rule can be specified for file suffixes. The rule has the form:

.fromext.toext : command

Where:fromext is the file extension of the dependenttoext is the file extension of the targetcommand is the build command

For example, to build an object file from a Fortran source file with the .f90 extension, specify the following rule:

.f90.obj :lf95 -c $<

Whenever an object file depends on a Fortran source file with the .f90 extension, the build command is invoked by default, unless overridden by a local build command.



The TOOLS.INI fileCommands for NMAKE can be specified in the NMAKE section of a file called TOOLS.INI. When NMAKE is invoked, it looks for the TOOLS.INI file in the current directory, or in the location specified by the INIT environment variable. The TOOLS.INI file is a good place to define LF95 as the Fortran compiler, and to specify suffix build rules. A typical TOOLS.INI file for LF95 might look like this:

[NMAKE]

FC = lf95

DEBUG = -g -trace -info -f95 -stchk -chk

OPTIMIZE = -o1 -ntrace -ndal

.f90.obj :

$(FC) -c $<

.for.obj :

$(FC) -c $<

.f.obj :

$(FC) -c $<

When a file like this is available to NMAKE, the macros and default build commands defined here become the default, and are used unless overridden by a local build command.

Example: Building a libraryThe following makefile builds a library from three source files. It can easily be adapted for general use by replacing the SRCS and TARGET macros with the pertinent source file and library names.

FC = lf95

SRCS = one.f90 two.f90 three.f90

TARGET = foo.lib

$(TARGET) : $(SRCS)

$(FC) $? -out $@

The FC macro names LF95 as the compiler. The SRCS macro is a list of source files which comprise the library contents. The TARGET macro defines the library name.

The library will only be updated if the source file is newer than the library file, it does not depend on the presence or status of object files. If the library does not exist when NMAKE is invoked, LF95 is used to create the library. If the library is already present when NMAKE is invoked, LF95 in used to update the library.


Example: Building a program with module dependencies

Example: Building a program with module dependenciesThis example makefile builds a program consisting of three files, a main program and two modules. The main program (main.f90) uses a module (mod2.f90), which itself uses another module (mod1.f90). The order that the files are compiled in is critical, because any module that is used must be compiled before the procedure that uses it. If mod1.f90 is changed, all the source files must be recompiled in the order mod1.f90, mod2.f90, main.f90, to satisfy the use requirement. If mod2.f90 is changed, mod1.f90 does not need to be recompiled, but mod2.f90 and main.f90 must be recompiled in order. Because of these requirements, the dependencies need to be written in a way that ensures the correct files are compiled, in the correct order.

FC = lf95.f90.obj :

$(FC) -c $<OBJS = main.obj mod1.obj mod2.objTARGET = main.exe$(TARGET) : $(OBJS)

$(FC) $(OBJS) -out $@

main.obj : mod2.obj main.f90

mod2.obj : mod1.obj mod2.f90

mod1.obj : mod1.f90

When the dependency rule for a module-dependent object file is specified, the object will depend on both the object file from the used module along with the object’s source file. If the used module is out of date, it’s build rule will be invoked before the module-using source file is compiled.

Example: Building multiple targetsThis example makefile builds a program that directly uses two modules and also links to a library. If the library is out of date, it is updated and the program is relinked. The build pro-cess must also make sure that any out of date module is recompiled as well as the procedure that uses it, in the proper order. This makefile depends on the definitions shown in the TOOLS.INI file described in the above section, and assumes that the TOOLS.INI file is either in the current directory, or pointed to by the INIT environment variable.

OBJS = main.obj mod1.obj mod2.objTARGET = main.exe

FLIB = LIBLIBSRCS = one.f90 two.f90 three.f90LIBTARGET = foo.lib

$(TARGET) : $(OBJS) $(LIBTARGET)



$(FC) $(OBJS) $(LIBTARGET) -out $@

main.obj : mod1.obj mod2.obj main.f90

mod2.obj : mod2.f90

mod1.obj : mod1.f90

$(LIBTARGET) : $(LIBSRCS)$(FC) $? -out $@


9 The Sampler Tool

Tuning a program can significantly reduce its execution time. A specific section of a program may take most of the processing time, so tuning that section may greatly speed up the pro-cessing of the program. The Sampler tool helps you tune programs and detect bottlenecks.

Remarks:

1. When you tune a program, start by checking the cost for each function. If the cost of a func-tion is high, the following two factors may be causes:a. The function may include a redundant section.b. The function itself may have no problems; however, it may be called excessively.

For the first cause, check the cost of the function source. For the second cause, check the source cost of the function calling this function.

2. The cost described in this chapter is the summed result of execution locations extracted per a specific time unit (per second, for example) based on a given sampling frequency. To illus-trate, the cost of function f in a program is the number of locations belonging to f from the locations extracted per a specific time value.

Starting and Terminating the Sampler

Starting the SamplerWhen the Sampler is started, the last used sample data file name and the executable file name is restored.

There are two ways to start the sampler:

1. From the Windows desktop icon2. From the Windows command prompt


Chapter 9 The Sampler Tool

Starting from the Sampler iconStart the sampler by double-clicking the Sampler icon on your Windows desktop if you chose to have an icon at installation time; otherwise start it from the Start|Programs menu.

Starting from the Command promptType

SAMP

followed by the <Enter> key.

Terminating the SamplerTo terminate the sampler, choose the Exit Sampler command from the File menu in the sam-pler window.

The Sampler WindowSee the figure below for the sampler window.


Sampler Menus

The above figure illustrates the following items:

1. The Toolbar, which contains icons that activate frequently used commands. These commands can also be executed from the Menu Bar.

2. The Status Bar, which displays an explanation of each menu command.3. The “Function Cost” and “Calling Tree” windows, which are described later in this

chapter.

Sampler MenusThe sampler menus are outlined below.

File MenuThe table below lists the File menu commands.

Remarks:

• When the "OK" button in the "Select Files" dialogbox is clicked, the "Executable File and Sample Data File" window appears.

• The “Print” and “Print Preview” commands are displayed only if tuning information is being displayed.

• The “Print” and “Print Preview” commands cannot be used for the function calling relationship diagram.

Table 21: Commands for the File Menu

Command Function

Select Files Open dialog for selecting executable (.exe) file and specifying sampling data output (.smp) file.

Print Print the displayed tuning information

Print Preview Display pages as they would appear if printed

Print Setup Configure the printer

Exit Sampler Terminate the Sampler



Sampler MenuThe table below lists the Sampler menu commands.

View MenuThe table below lists the View menu commands.

Table 22: Commands in the Sampler Menu

Command Function

Execute Run the program to collect tuning information

Executing OptionsSpecify command line arguments and runtime

options to the program and execute the program to collect tuning information

Function Cost Display the cost for each function

Source Cost Display the cost for each program unit

Calling Tree Display the function calling relationship diagram (calling tree)

Program Type: Fortran Specify whether to display Fortran programinformation for the Sampler Data

Program Type: C Specify whether to display C programinformation for the Sampler Data

Program Type: OtherSpecify whether to display information other than C

or Fortran program information for the Sampler Data.

Source File Directory Specify the source file directory

Table 23: Commands in the View Menu

Command Function

Status Bar Specify whether to display the status bar.

Toolbar Specify whether to display the toolbar.

File Information Specify whether to display file information


Using the Sampler

Window MenuThe table below lists the Window menu commands.

Note: the Window menu is displayed only if tuning information is being displayed.

Help MenuThe table below lists the Help menu commands.

Using the SamplerThe functions of the sampler are listed below. This section explains how to use these functions.

• Collecting the tuning information• Displaying the tuning information

Table 24: Commands in the Window Menu

Command Function

Cascade Display all open windows so that they overlap, revealing the Title bar for each window.

Tile Horizontally Display the listed tuning information from left to right.

Tile Vertically Display the listed tuning information from top to bottom.

Arrange Icons Arrange all the icons along the bottom of the win-dow.

Close All Close all open windows

Table 25: Commands in the Help Menu

Command Function

Help Topics Display the Sampler help topics

About Sampler Display version information for the Sampler.



Collecting Tuning InformationIn order to generate tuning information, the program must be compiled with the -trace option (see ”-[N]TRACE” on page 35). To collect tuning information, run the program once, following the steps outlined below:

1. In the sampler, select the “Select Files...” command from the File menu. The Select Files dialog box appears.

2. Specify the Sample Data File, either by typing it in or browsing. The file must have an extension of .smp. Note that selection through browsing will set the default directory.

3. Specify the Executable File, either by typing it in or browsing. The file must have an extension of .exe.

4. Select one of the following methods of running the program:

To run the program with the existing execution options:a. Select the “Execute” command from the Sampler menu to run the program and col-

lect its tuning information, allowing the program to terminate normally.b. To abort execution, click the Stop button in the window that is displayed while the

program is running (this may interfere with generation of sampler data).

To run the program with modified execution options (i.e., command-line arguments):a. Select the “Executing Options” command from the Sampler menu. The Executing

Options dialog box appears.b. In the Executing Options dialog box, specify the executing option. If the user pro-

gram uses default input-output, specify a redirection function such as “<“ or “>” in the executing option.

c. Click the OK button.d. Execute the program and collect its tuning information, allowing it to terminate

normally.e. To abort execution, click the Stop button in the window that is displayed while the

program is running (this may interfere with generation of sampler data).

Note: In Windows 9x, if the message “Out of environment space” is displayed while running a console-mode program from the Sampler, it means the environment space of the DOS shell must be increased. This may be accomplished by adding the line (assuming that the system install directory is “c:\windows”)

SHELL=C:\WINDOWS\COMMAND.COM /P /E:32768

to the CONFIG.SYS file. It may also be accomplished by modifying the “Initial Environ-ment” property of the file COMMAND.COM using Windows explorer.

Displaying Tuning InformationThe sampler displays the following three items of tuning information.


Displaying the Cost for Each Function

• Cost for each function• Cost per line of the source level• Function calling relationship diagram

Recompilation is not required for an object generated with the Fujitsu Fortran compiler. To use the C compiler, specify the /Kline option at compilation.

The method of displaying each item of information is listed below.

Displaying the Cost for Each FunctionDo the following to display the cost for each program unit:

In the sampler window, select the Function command from the Display menu. The func-tion cost window appears. (See the figure below.)

Displaying the Cost Per LineDo the following to display the cost per line of the source level:

1. In the sampler window, select the Source command from the Display menu. The Open File dialog box appears.

2. In the Open File dialog box, select the corresponding source program and click the Open button. The cost per line of the source level appears. (See the figure below for function cost per line of the source level window.)

The following procedures can also be used to display the cost per line of the source level:



Double clicking the function name that corresponds to the source code in the function cost window also shows the cost per line of the source code level.

The Calling Relationship DiagramDo the following to display the function calling relationship diagram.

1. In the sampler window, select the Reference command from the Display menu.

2. The calling tree window appears. (See the figure below for the calling tree window.)

Click the left button in the box of file names in the calling tree window to display the Focus and Detail menus. Select the Focus menu to display the calling relationship diagram from the function; select the Detail menu to display detailed information. If the Focus Level is more


The Calling Relationship Diagram

than 1, press the left button outside the box to display the Top Level and Previous Level menus. Select the Top Level menu to display the relationship diagram of jump level 1. Select the Previous Level menu to display the previous relationship diagram.

Note: The cost information per line of the source level may differ slightly from the actual cost, because it is affected by the measuring machine status when information is collected (such as machine load status, number of logging users, and number of demons). The cost for each function always has about the same rate for the same program.


10 The Coverage Tool

One approach to program testing is to verify the operation range and coverage of the program execution. The Coverage Tool provides the following information for programs coded in the Fortran or C language:

• Executed and non executed section information for each basic unit of execution flow• Execution coverage information for each subroutine and function

Starting and Terminating the Coverage Tool

Starting the Coverage ToolWhen the Coverage is started, the last used sample data file name and the executable file name is restored.

There are two ways to start the Coverage Tool:

1. From the Windows desktop icon2. From the Windows command prompt

Starting from the desktop iconStart by double-clicking the Coverage Tool icon on your Windows desktop if you chose to have an icon at installation time; otherwise start it from the Start|Programs menu.

Starting from the Command promptType

COV

followed by the <Enter> key.


Chapter 10 The Coverage Tool

Terminating the Coverage ToolIn the coverage window, terminate the coverage tool by selecting the Exit Coverage com-mand from the File menu.

Coverage WindowSee the figure below for the coverage window.

The above figure illustrates the following items:

1. The Toolbar, which contains icons that activate frequently used commands. These com-mands can also be executed from the Menu Bar.

2. The Status Bar, which displays an explanation of each menu command.

Coverage MenusThe coverage menus are outlined below.


File Menu

File MenuThe table below lists the File menu commands.

When the "OK" button in the "Select Files" dialogbox is clicked, the "Excutable File and Sample Data File" window appears.

The Print, and Print Preview commands are active only if coverage information is being displayed.

Coverage MenuThe table below lists the Coverage menu commands.

Table 26: Commands in the File Menu

Command Function

Select Files Open dialog for selecting executable (.exe) file and specifying coverage data output (.cov) file

Print Print the coverage information being displayed.

Print Preview Display image as it would be printed

Print Setup Specify printer configuration.

File Search Path Specify the path for searching for the file.

Exit Coverage Terminate the coverage tool.

Table 27: Commands in the Coverage Menu

Command Function

Execute Run the program to collect coverage information.

Executing Options

Submit command line argument(s) and runtime options to the program and execute the program to

collect coverage information

ExecutionCoverage Rate

Display the coverage information for all program units

Source File Directory Specify the source file directory



View MenuThe table below lists the View menu commands.

Window MenuThe table below lists the Window menu commands.

Note: the Window menu is displayed only if coverage information is being displayed.

Table 28: Commands in the View Menu

Command Function

File Information Displays a dialog showing information about the executable file and the coverage data file.

Status Bar Specifies whether to display the status bar.

Toolbar Specifies whether to display the toolbar.

Table 29: Commands in the Window Menu

Command Function

Cascade Displays all open windows so that they overlap, revealing the Title Bar for each window.

Tile Horizontally Displays the listed coverage information from left to right.

Tile Vertically Displays the listed coverage information from top to bottom.

Arrange Icons Arranges all the icons along the bottom of the win-dow.

Close All Close all open windows


Help Menu

Help MenuThe table below lists the Help menu commands.

Using the Coverage ToolTo compile a source program for the collection of coverage information, you must specify -cover as an option at compilation. If the source program is compiled without the -cover option specified, coverage information is not collected.

The coverage functions are listed below.

• Collecting coverage information• Displaying coverage information

Collecting Coverage InformationTo collect coverage information, run the program once.

Do the following to collect the information:

1. In the Coverage tool, select the “Select Files...” command from the File menu. The Select Files dialog box appears.

2. Specify the Coverage Data File, either by typing it in or browsing. The file must have an extension of .cov. Note that selection through browsing will set the default directory.

3. Specify the Executable File, either by typing it in or browsing. The file must have an extension of .exe.

4. Select one of the following methods for executing the program:

To execute the program with the existing execution options:a. Select the “Execute” command from the Coverage menu to run the program and col-

lect its coverage information, allowing the program to terminate normally.b. To abort execution, click the Stop button in the window that is displayed while the

program is running (this may interfere with generation of coverage data).

Table 30: Commands in the Help Menu

Command Function

Help Displays the Coverage Tool help topics

About Coverage Displays version information for the coverage tool.



To execute the program with modified execution options (i.e., command-line arguments):a. Select the “Executing Options” command from the Coverage menu. The Executing

Options dialog box appears.b. In the Executing Options dialog box, specify the executing option. If the user pro-

gram uses default input-output, specify a redirection function such as '<' or '>' in the option.

c. Click the OK button.d. Run the program and collect its coverage information, allowing the program to ter-

minate normally.e. To abort execution, click the Stop button in the window that is displayed while the

program is executing (this may interfere with generation of coverage data).

Note: In Windows 9x, if the message “Out of environment space” is displayed while running a console-mode program from the Coverage Tool, it means the environment space of the DOS shell must be increased. This may be accomplished by by adding the line (assuming that the system install directory is “c:\windows”)

SHELL=C:\WINDOWS\COMMAND.COM /P /E:32768

to the CONFIG.SYS file. It may also be accomplished by modifying the “Initial Environ-ment” property of the file COMMAND.COM using Windows explorer.

Storing & Merging Coverage InformationCollected coverage information can be stored. You can update and display the stored infor-mation by assigning another argument to the executable program (merging the information). If the program being tested requires input data, you can put sample data into a file and then use that data for testing the program.

Storing Coverage InformationCoverage information is stored in the file specified by the “Select Coverage Data File” com-mand in the File menu.

Merging Coverage InformationFollow these steps to merge coverage information with the existing coverage data file:

1. Use the “Select Coverage Data File” command in the File menu to specify the data file containing the collected coverage information.

2. Use the “Select Executable File” command in the File menu to specify the same exe-cutable file generated by (1) above as the Executable File.


Displaying Coverage Information

3. Select the “Execute” or “Executing Options” command from the Coverage menu to execute the program and collect its coverage information.

The new coverage information is now stored in the specified data file.

Displaying Coverage InformationThe following items are displayed in the coverage information:

• Run coverage rate for each subroutine and function

• Executed and non executed section corresponding to the source code

Follow these steps to display the information:

1. Select the “Select Coverage Data File” command from the File menu. The Coverage Data File dialog box appears.

2. In the Coverage Data File dialog box, specify the coverage data file.

3. Select the “Select Executable File” command from the File menu. The Executable File dialog box appears.

4. In the Executable File dialog box, specify the executable file.

5. Select the “Function” command from the Display menu to display the execution cov-erage rate for each subroutine and function. (See the first figure below.) Then double-click the subroutine or function to display the executed and non executed sections of the corresponding source code. (See the second figure below.)



Remarks:

1. The coverage tool shows the executed and non executed parts of each block. A block is a set of statements that do not change the control of execution. The following instances may separate a block:

a. Fortran: IF, CASE, DO and GOTOb. C language: if, case, for and label

2. The following marks are placed at the beginning of the block:

a. Blue foot mark: the block which is executed for the first timeb. White foot mark: the block which is executed for the second or subsequent times.c. Stick mark: the block that is never executed.


11 Utility Programs

This chapter documents the following utility programs:

• DUMPBIN.EXE• EDITBIN.EXE• HDRSTRIP.F90• LFSPLIT.EXE• MAKEDEF.EXE• SEQUNF.F90• TRYBLOCK.F90• UNFSEQ.F90• WHERE.EXE

DUMPBIN.EXEDUMPBIN.EXE allows you to display information about COFF object files, libraries of COFF object files, executable files, and dynamic-link libraries. Information can be displayed in both hexadecimal and ASCII character formats.

Invoking DUMPBINDUMPBIN is invoked from the command prompt using the following syntax:

dumpbin [options] files

DUMPBIN OptionsOptions are distinguished by using an option specifier, which consists of a leading “/” or “-” character, followed by the option name. Options and filenames may be separated by the space or tab characters. Options and filenames are not case sensitive. If no options are spec-ified, the default option is /SUMMARY.


Chapter 11 Utility Programs

Option listNote that some options for DUMPBIN may not apply to files built with LF95. Only options known to be valid for files built with LF95 are described.

-ALLDisplays everything except disassembly. Use /RAWDATA:NONE with the /ALL option to prevent display of raw binary details.

-ARCHIVEMEMBERSDisplays information about objects in a library.

-DEPENDENTSDisplays the name of any DLL needed by an executable or DLL.

-DISASMDisplays code disassembly.

-EXPORTSDisplays all symbols exported by a DLL.

-HEADERSDisplays coff header information.

-IMPORTSDisplays all symbols imported by an executable or DLL.

-LINKERMEMBER[:lev]Displays public symbols defined in a library. If the lev argument is 1, display symbols in object order, along with their offsets. If the lev argument is 2, display offsets and index num-bers of objects, then list the symbols in alphabetical order along with the object index for each. If the lev argument is not present, both outputs are displayed.

-OUT:filenameSends output to the specified file instead of to the console.

-RAWDATA:optionDisplays the raw contents of each section in the file. The option argument controls the format of the display, as follows:

BYTES - Default setting. Contents are displayed in hexadecimal bytes, and in ASCII.SHORTS - Contents are displayed in hexadecimal words.LONGS - Contents are displayed in hexadecimal long words.NONE - Display of raw data is suppressed.number - Controls the number of values displayed per line.

-RELOCATIONSDisplays any relocations in the object or image.

-SECTION:sectionRestricts output to the specified section.


EDITBIN.EXE

-SUMMARYDefault option. Displays minimal information about the file.

-SYMBOLSDisplays the COFF symbol table for an object file or library.

EDITBIN.EXEEDITBIN.EXE allows you to edit information in COFF object files, libraries of COFF object files, executable files, and dynamic-link libraries. EDITBIN can also be used to convert object model format files (OMF) to common object file format (COFF). To convert from OMF to COFF, run EDITBIN with no options.

Invoking EDITBINEDITBIN is invoked from the command prompt using the following syntax:

editbin [options] files

EDITBIN OptionsOptions are distinguished by using an option specifier, which consists of a leading “/” or “-” character, followed by the option name. Options and filenames may be separated by the space or tab characters. Options and filenames are not case sensitive.

Option list-BIND[:PATH=path]Sets the addresses of the entry points in the import address table for an executable file or DLL. Use this option to reduce load time of a program. The optional path argument specifies the location of any DLLs. Separate multiple directories with semicolons. If path is not spec-ified, EDITBIN searches the directories specified in the PATH environment variable. If path is specified, EDITBIN ignores the PATH variable.

-HEAP:reserve[,commit]Sets the size of the heap in bytes. Numbers are specified in decimal format.

The reserve argument specifies the total heap allocation in virtual memory. The default heap size is 1MB. The linker rounds the specified value up to the nearest 4 bytes.

The optional commit argument specifies the amount of physical memory to allocate at a time. Committed virtual memory causes space to be reserved in the paging file. A larger commit value saves time when the application needs more heap space but increases the memory requirements and possibly startup time.

-LARGEADDRESSAWAREEdits the image to indicate that the application can handle addresses larger than 2 gigabytes.



-NOLOGOSuppresses display of the EDITBIN copyright message and version number.

-REBASE[:modifiers]Sets the base addresses for the specified files. Assigns new base addresses in a contiguous address space according to the size of each file rounded up to the nearest 64K. Numbers are specified in decimal format. One or more optional modifiers are separated by a comma:

BASE=address - Beginning address for reassigning base addresses to the files. If BASE is not specified, the default starting base address is 0x400000. If DOWN is used, BASE must be specified, and address sets the end of the range of base addresses.

BASEFILE - Creates a file named COFFBASE.TXT, which is a text file in the format expected by LINK's /BASE option.

DOWN - Reassign base addresses downward from an ending address. Files are reassigned in the order specified, with the first file located in the highest possible address below the end of the address range. BASE must be used with DOWN to ensure sufficient address space for basing the files. To determine the address space needed by the specified files, run EDITBIN with the /REBASE option on the files and add 64K to the displayed total size.

-RELEASESets the checksum in the header of an executable file.

-SECTION:name[=newname][,properties][,alignment]Changes the properties of a section, overriding the properties that were set when the object file for the section was compiled or linked. properties and alignment characters are specified as a string with no white space.

name is the name of the section to modify.

newname is the new section name.

properties is a comma separated list of characters. To negate a property, precede its character with an exclamation point (!). The following properties may be specified:

c - coded - discardablee - executablei - initialized datak - cached virtual memorym - link removeo - link infop - paged virtual memoryr - reads - sharedu - uninitialized dataw - write


HDRSTRIP.F90

alignment is specified by the character "a" followed by a character to set the size of alignment in bytes, as follows:

1 - 1 byte2 - 2 bytes4 - 4 bytes8 - 8 bytesp - 16 bytest - 32 bytess - 64 bytesx - no alignment

-STACK:reserve[,commit]Sets the size of the stack in bytes. Numbers are specified in decimal format. The /STACK option applies only to an executable file.

The reserve argument specifies the total heap allocation in virtual memory. The default heap size is 1MB. The linker rounds the specified value up to the nearest 4 bytes.

The optional commit argument specifies the amount of physical memory to allocate at a time. Committed virtual memory causes space to be reserved in the paging file. A larger commit value saves time when the application needs more heap space but increases the memory requirements and possibly startup time.

-SUBSYSTEM:system[,major[.minor]]Edits the image to indicate which subsystem the operating system must invoke for execution.

Tells the operating system how to run the executable file. system is specified as follows:

CONSOLE - Used for Win32 character-mode applications.

WINDOWS - Used for applications that do not require a console.

The optional major and minor version numbers specify the minimum required version of the subsystem.

-VERSION:left[,right]Places a version number into the header of the image. left indicates the portion of the version number that appears to the left of the decimal point. right indicates the portion of the version number that appears to the right of the decimal point.

HDRSTRIP.F90HDRSTRIP.F90 is a Fortran source file that you can compile, link, and execute with LF95. It converts LF90 direct-access files to LF95 style.



LFSPLIT.EXERun LFSPLIT.EXE to divide a source file into new separate source files, one for each main program, subroutine, function or module. Each new source file will have a filename of the sub-program unit name and the same extension as the original file.

Type lfsplit -help at the command prompt for more details about use of the file splitter.

MAKEDEF.EXEUse MAKEDEF.EXE to create a definition file listing all exported symbols from a DLL. The definition file is used by LIB.EXE to create an import library. MAKEDEF accepts a single DLL file including the .dll extension as a command line argument, and creates a file with the same name having the .def extension. If a definition file with this name already exists, it is overwritten. MAKEDEF ignores all exported symbols that contain three or more sequential underscore characters. The MAKEDEF utility requires that DUMPBIN.EXE be available in a directory on the path. See “Creating import libraries” on page 136 for instructions on gen-erating an import library.

SEQUNF.F90SEQUNF.F90 is a Fortran source file that you can compile, link, and execute with LF95. It converts LF90 unformatted sequential files to LF95 style.

TRYBLK.F90TRYBLK.F90 is a Fortran source file you can build with LF95. It tries a range of blocksizes and displays an elapsed time for I/O operations with each bocksize. You can use the results to determine an optimum value for your PC to specify in your programs. Note that a partic-ular blocksize may not perform as well on other PC’s.

UNFSEQ.F90UNFSEQ.F90 is a program that converts LF95 unformatted sequential files to LF90 style.


WHERE.EXE

WHERE.EXEWHERE.EXE can be used to locate files on the path or in directories, and to display the exe type, time and size of the file.

Invoking WHEREWHERE is invoked with the following syntax:

WHERE [/r dir] [/Qqte] pattern ...

Where:/r dir recursively search directories under dir/Q display output files in double quotes/q quiet mode, exit code of zero indicates file found/t display file size and time/e display executable typepattern is one or more file specifications, with the wildcards, * ?, allowed

If /r is not specified, WHERE searches along the path.

Exampleswhere lf95.exe

Searches along the path for all occurences of LF95.

where /te /r \windows user32.dll

Recursively searches all directories under \windows for all occurences of USER32.DLL, and lists each file size and creation time, and the executable type.


A Programming Hints

This appendix contains information that may help you create better LF95 programs.

Efficiency ConsiderationsIn the majority of cases, the most efficient solution to a programming problem is one that is straightforward and natural. It is seldom worth sacrificing clarity or elegance to make a pro-gram more efficient.

The following observations, which may not apply to other implementations, should be con-sidered in cases where program efficiency is critical:

• One-dimensional arrays are more efficient than two, two are more efficient than three, etc.

• Make a direct file record length a power of two.• Unformatted input/output is faster for numbers.• Formatted CHARACTER input/output is faster using:

CHARACTER*256 C

than:CHARACTER*1 C(256)

Side EffectsLF95 arguments are passed to subprograms by address, and the subprograms reference those arguments as they are defined in the called subprogram. Because of the way arguments are passed, the following side effects can result:

• Declaring a dummy argument as a different numeric data type than in the calling pro-gram unit can cause unpredictable results and NDP error aborts.


Appendix A Programming Hints

• Declaring a dummy argument to be larger in the called program unit than in the call-ing program unit can result in other variables and program code being modified and unpredictable behavior.

• If a variable appears twice as an argument in a single CALL statement, then the cor-responding dummy arguments in the subprogram will refer to the same location. Whenever one of those dummy arguments is modified, so is the other.

• Function arguments are passed in the same manner as subroutine arguments, so that modifying any dummy argument in a function will also modify the corresponding argument in the function invocation:

y = x + f(x)

The result of the preceding statement is undefined if the function f modifies the dummy argument x.

File Formats

Formatted Sequential File Format

Files controlled by formatted sequential input/output statements have an undefined length record format. One Fortran record corresponds to one logical record. The length of the unde-fined length record depends on the Fortran record to be processed. The max length may be assigned in the OPEN statement RECL= specifier. The carriage-return/line-feed sequence terminates the logical record. If the $ edit descriptor or \ edit descriptor is specified for the format of the formatted sequential output statement, the Fortran record does not include the carriage-return/line-feed sequence.

Unformatted Sequential File Format

Files processed using unformatted sequential input/output statements have a variable length record format. One Fortran record corresponds to one logical record. The length of the vari-able length record depends on the length of the Fortran record. The length of the Fortran record includes 4 bytes added to the beginning and end of the logical record. The max length may be assigned in the OPEN statement RECL= specifier. The beginning area is used when an unformatted sequential statement is executed. The end area is used when a BACKSPACE statement is executed.


Direct File Format

Direct File Format Files processed by unformatted direct input/output statements have a fixed length record for-mat, with no header record. One Fortran record can correspond to more than one logical record. The record length must be assigned in the OPEN statement RECL= specifier. If the Fortran record terminates within a logical record, the remaining part is padded with binary zeros. If the length of the Fortran record exceeds the logical record, the remaining data goes into the next record.

Transparent File Format Files opened with ACCESS=”TRANSPARENT” or FORM=”BINARY” are processed as a stream of bytes with no record separators. While any format of file can be processed trans-parently, you must know its format to process it correctly.

Determine Load Image SizeTo determine the load image size of a protected-mode program, add the starting address of the last public symbol in the linker map file to the length of that public symbol to get an approximate load image memory requirement (not execution memory requirement).

Link TimeCertain code can cause the linker to take longer. For example, using hundreds to thousands of named COMMON blocks causes the linker to slow down. Most of the additional time is spent in processing the names themselves because Windows (requires certain ordering rules to be followed within the executable itself.

You can reduce the link time by reducing the number of named COMMON blocks you use. Instead of coding:

common /a1/ i

common /a2/ j

common /a3/ k

...

common /a1000/ k1000

code:

common /a/ i,j,k, ..., k1000

Link time may also be reduced by using the -NOMAP option.



Year 2000 complianceThe "Year 2000" problem arises when a computer program uses only two digits to represent the current year and assumes that the current century is 1900. A compiler can look for indi-cations that this might be occurring in a program and issue a warning, but it cannot foresee every occurrence of this problem. It is ultimately the responsibility of the programmer to cor-rect the situation by modifying the program. The most likely source of problems for Fortran programs is the use of the obsolete DATE() subroutine. Even though LF95 will compile and link programs that use DATE(), its use is strongly discouraged; the use of DATE_AND_TIME(), which returns a four digit date, is recommended in its place.

LF95 can be made to issue a warning at runtime whenever a call to DATE() is made. This can be accomplished by running a program with the runtime options -Wl,Ry,li for example,

myprog.exe -Wl,Ry,li

For more information on runtime options, see “Runtime Options” on page 191.


Limits of Operation.

Limits of Operation.Table 31: LF95 Limits of Operation

Item Maximum

program size

The compiler limits code and data to 4 Gigabytes or available memory (includ-ing virtual memory), whichever is smaller. Because this limit is larger than operating systems allow, program size is effectively limited by the operating sys-tem, not the compiler.For the Windows 95 or Windows NT 4.0 (prior to SP3) operating systems, a pro-gram is limited to 256 megabytes or avail-able memory (including virtual memory), whichever is smaller.For the Windows XP/2000/NT4(SP3+)/Me/98 operating systems, programs are limited to 2 gigabytes or available mem-ory (including virtual memory), which-ever is smaller. This can be increased to 3 gigabytes if the /3GB switch is used in the Boot.ini file.

number of files open concurrently Not limited by LF95 language system.

Length of CHARACER datum 2,147,483,647 bytes

I/O block size 65,000 bytes

I/O record length 2,147,483,647 bytes

I/O file size (including transparent access) 18,446,744,073,709,551,614 bytes

I/O maximum number of records for direct access and transparent access files 2,147,483,647

nesting depth of function, array section, array element, and substring references 255

nesting depth of DO, CASE, and IF state-ments 50

nesting depth of implied-DO loops 25



nesting depth of INCLUDE files 16

number of array dimensions 7

array size

The compiler calculates T for each array declaration to reduce the number of calcu-lations needed for array sections or array element addresses. The absolute value of T obtained by the formula below must not exceed 2147483647, and the absolute value must not exceed 2147483647 for any intermediate calculations:

n: Array dimension numbers: Array element lengthl: Lower bound of each dimensiond: Size of each dimensionT: Value calculated for the array declara-tion

Table 31: LF95 Limits of Operation

Item Maximum

T l1 s li dm 1 s×–m 2=

i

∏

×

i 2=

n

∑+×=


B Runtime Options

The behavior of the LF95 runtime library can be modified at the time of execution by a set of commands which are submitted via the command line when invoking the executable pro-gram, or via shell environment variables. These runtime options can modify behavior of input/output operations, diagnostic reporting, and floating-point operations.

Runtime options submitted on the command line are distinguished from user-defined com-mand line arguments by using a character sequence that uniquely identifies the runtime options, so that they will not interfere with the passing of regular command line arguments that the user’s program might be expecting to obtain via the GETCL(), GETPARM(), or GETARG() functions.

Command FormatRuntime options and user-defined executable program options may be specified as command option arguments of an execution command. The runtime options use functions supported by the LF95 runtime library. Please note that these options are case-sensitive.

The format of runtime options is as follows:

exe_file [/Wl,[runtime options],...] [user-defined program arguments]...

Where exe_file indicates the user’s executable program file. The string “/Wl,” (or “-Wl,”) must precede any runtime options, so they may be identified as such and distinguished from user-defined program arguments. Note that it is W followed by a lowercase L (not the number one). Please note also that if an option is specified more than once with different arguments, the last occurrence is used.


Appendix B Runtime Options

Command Shell VariableAs an alternative to the command line, the shell variable FORT90L may be used to specify runtime options. Any runtime options specified in the command line are combined with those specified in FORT90L. The command line arguments take precedence over the correspond-ing options specified in the shell variable FORT90L.

The following examples show how to use the shell variable FORT90L (the actual meaning of each runtime option will be described in the sections below):

Example 1:Setting the value of shell variable FORT90L and executing the program as such:

set FORT90L=-Wl,e99,lea.exe -Wl,m99 /k

has the same effect as the command line

a.exe -Wl,e99,le,m99 /k

The result is that when executing the program a.exe, the runtime options e99, le, and m99, and user-defined executable program argument /k are in effect.

Example 2:When the following command lines are used,

set FORT90L=-Wl,e10a.exe -Wl,e99

the result is that a.exe is executed with runtime option /e99 is in effect, overriding the option e10 set by shell variable FORT90L.


Execution Return Values

Execution Return ValuesThe following table lists possible values returned to the operating system by an LF95 execut-able program upon termination and exit. These correspond to the levels of diagnostic output that may be set by various runtime options:

Standard Input and OutputThe default unit numbers for standard input, output, and error output for LF95 executable programs are as follows, and may be changed to different unit numbers by the appropriate runtime options:

Standard input: Unit number 5Standard output: Unit number 6Standard error output: Unit number 0

Runtime OptionsRuntime options may be specified as arguments on the command line, or in the FORT90L shell variable. This section explains the format and functions of the runtime options. Please note that all runtime options are case-sensitive.

The runtime option format is as follows:

Table 32: Execution Return Values

Return value Status

0 No error or level I (information message)

4 Level W error (warning)

8 Level E error (medium)

12 Level S error (serious)

16 Limit exceeded for level W, E, S error, or a level U error (Unrecoverable) was detected

240 Abnormal termination

Other Forcible termination



/Wl [,Cunit] [,M] [,Q] [,Re] [,Rm:file] [,Tunit] [,a] [,dnum] [,enum] [,gnum] [,i] [,lelvl] [,munit] [,n][,punit] [,q] [,runit] [,u] [,x]

When runtime options are specified, the string “/Wl” (where l is lowercase L) is required at the beginning of the options list, and the options must be separated by commas. If the same runtime option is specified more than once with different arguments, the last occurrence is used.

Example:a.exe /Wl,a,p10,x

Description of Options

C or C[unit] The C option specifies how to process an unformatted file of IBM370-format floating-point data using an unformatted input/output statement. When the C option is specified, the data of an unformatted file associated with the specified unit number is regarded as IBM370-format floating-point data in an unformatted input/output statement. The optional argument unit specifies an integer from 0 to 2147483647 as the unit number. If optional argument unit is omitted, the C option is valid for all unit numbers connected to unformatted files. When the specified unit number is connected to a formatted file, the option is ignored for the file. When the C option is not specified, the data of an unformatted file associated with unit number unit is regarded as IEEE-format floating-point data in an unformatted input-output statement.

Example: a.exe /Wl,C10

MThe M option specifies whether to output the diagnostic message (jwe0147i-w) when bits of the mantissa are lost during conversion of IBM370-IEEE-format floating-point data. If the M option is specified, a diagnostic message is output if conversion of IBM370-IEEE-format floating-point data results in bits of the mantissa being lost. When the M option is omitted, the diagnostic message (jwe0147i-w) is not output.

Example:a.exe /Wl,M

QThe Q option suppresses padding of an input field with blanks when a formatted input state-ment is used to read a Fortran record. This option applies to cases where the field width needed in a formatted input statement is longer than the length of the Fortran record and the file was not opened with and OPEN statement. The result is the same as if the PAD= specifier in an OPEN statement is set to NO. If the Q option is omitted, the input record is padded with blanks. The result is the same as when the PAD= specifier in an OPEN statement is set to YES or when the PAD= specifier is omitted.



Example:a.exe /Wl,Q

ReDisables the runtime error handler. Traceback, error summaries, user control of errors by ERRSET and ERRSAV, and execution of user code for error correction are suppressed. The standard correction is processed if an error occurs.

Example: a.exe /Wl,Re

Rm: filenameThe Rm option saves the following output items to the file specified by the filename argument:

• Messages issued by PAUSE or STOP statements• Runtime library diagnostic messages• Traceback map• Error summary

Example:a.exe /Wl,Rm:errors.txt

RyEnforces Y2K compliance at runtime by generating an i-level (information) diagnostic when-ever code is encountered which may cause problems after the year 2000A.D. Must be used in conjunction with li option in order to view diagnostic output.

Example: a.exe /Wl,Ry,li

T or T[u_no] Big endian integer data, logical data, and IEEE floating-point data is transferred in an unfor-matted input/output statement. The optional argument u_no is a unit number, valued between 0 and 2147483647, connected with an unformatted file. If u_no is omitted, T takes effect for all unit numbers. If both T and Tu_no are specified, then T takes effect for all unit numbers.

Example:a.exe /Wl,T10

aWhen the a option is specified, an abend is executed forcibly following normal program ter-mination. This processing is executed immediately before closing external files.



Example:a.exe /Wl,a

d[num] 1The d option determines the size of the input/output work area used by a direct access input/output statement. The d option improves input/output performance when data is read from or written to files a record at a time in sequential record-number order. If the d option is speci-fied, the input/output work area size is used for all units used during execution.

To specify the size of the input/output work area for individual units, specify the number of Fortran records in the shell variable FUnnBF where nn is the unit number (see“Shell Vari-ables for Input/Output” on page 199 for details). When the d option and shell variable are specified at the same time, the d option takes precedence. The optional argument num spec-ifies the number of Fortran records, in fixed-block format, included in one block. The optional argument num must be an integer from 1 to 32767. To obtain the input/output work area size, multiply num by the value specified in the RECL= specifier of the OPEN statement. If the files are shared by several processes, the number of Fortran records per block must be 1. If the d option is omitted, the size of the input/output work area is 4K bytes.

Example: a.exe /Wl,d10

e[num] The e option controls termination based on the total number of execution errors. The option argument num, specifies the error limit as an integer from 0 to 32767. When num is greater than or equal to 1, execution terminates when the total number of errors reaches the limit. If enum is omitted or num is zero, execution is not terminated based on the error limit. However, program execution still terminates if the Fortran system error limit is reached.

Example: a.exe /Wl,e10

gnumThe g option sets the size of the input/output work area used by a sequential access input/output statement. This size is set in units of kilobytes for all unit numbers used during exe-cution. The argument num specifies an integer with a value of 1 or more. If the g option is omitted, the size of the input/output work area defaults to 8 kilobytes.

The g option improves input/output performance when a large amount of data is read from or written to files by an unformatted sequential access input/output statement. The argument num is used as the size of the input/output work area for all units. To avoid using excessive memory, specify the size of the input/output work area for individual units by specifying the size in the shell variable fuxxbf, where xx is the unit number (see“Shell Variables for Input/Output” on page 199 for details). When the g option is specified at the same time as the shell variable fuxxbf, the g option has precedence.



Example:

a.exe /Wl,g10

iThe i option controls processing of runtime interrupts. When the i option is specified, the For-tran library is not used to process interrupts. When the i option is not specified, the Fortran library is used to process interrupts. These interrupts are exponent overflow, exponent under-flow, division check, and integer overflow. If runtime option -i is specified, no exception handling is taken. The u option must not be combined with the i option

Example:

a.exe /Wl,i

lerrlvl errlvl: { i | w | e | s }The l option (lowercase L) controls the output of diagnostic messages during execution. The optional argument errlvl, specifies the lowest error level, i (informational), w (warning), e (medium), or s (serious), for which diagnostic messages are to be output. If the l option is not specified, diagnostic messages are output for error levels w, e, and s. However, messages beyond the print limit are not printed.

i

The li option outputs diagnostic messages for all error levels.

w

The lw option outputs diagnostic messages for error levels w, e, s, and u.

e

The le option outputs diagnostic messages for error levels e, s, and u.

s

The ls option outputs diagnostic messages for error levels s and u.

Example:

a.exe /Wl,le

mu_noThe m option connects the specified unit number u_no to the standard error output file where diagnostic messages are to be written. Argument u_no is an integer from 0 to 2147483647. If the m option is omitted, unit number 0, the system default, is connected to the standard error output file. See “Shell Variables for Input/Output” on page 199 for further details.



Example:

a.exe /Wl,m10

nThe n option controls whether prompt messages are sent to standard input. When the n option is specified, prompt messages are output when data is to be entered from standard input using formatted sequential READ statements, including list-directed and namelist statements. If the n option is omitted, prompt messages are not generated when data is to be entered from standard input using a formatted sequential READ statement.

Example:

a.exe /Wl,n

pu_no The p option connects the unit number u_no to the standard output file, where u_no is an integer ranging from 0 to 2147483647. If the p option is omitted, unit number 6, the system default, is connected to the standard output file. See “Shell Variables for Input/Output” on page 199 for further details.

Example:

a.exe /Wl,p10

qThe q option specifies whether to capitalize the E, EN, ES, D, Q, G, L, and Z edit output char-acters produced by formatted output statements. This option also specifies whether to capitalize the alphabetic characters in the character constants used by the inquiry specifier (excluding the NAME specifier) in the INQUIRE statement. If the q option is specified, the characters appear in uppercase letters. If the q option is omitted, the characters appear in low-ercase letters. If compiler option -nfix is in effect, the characters appear in uppercase letters so the q option is not required.

Example:

a.exe /Wl,q

ru_no The r option connects the unit number u_no to the standard input file during execution, where u_no is an integer ranging from 0 to 2147483647. If the r option is omitted, unit number 5, the system default, is connected to the standard input file. See “Shell Variables for Input/Output” on page 199 for further details.


Shell Variables for Input/Output

Example: a.exe /Wl,r10

uThe u option controls floating point underflow interrupt processing. If the u option is speci-fied, the system performs floating point underflow interrupt processing. The system may output diagnostic message jwe0012i-e during execution. If the u option is omitted, the system ignores floating point underflow interrupts and continues processing. The i option must not be combined with the u option.

Example: a.exe /Wl,u

xThe x option determines whether blanks in numeric edited input data are ignored or treated as zeros. If the x option is specified, blanks are changed to zeros during numeric editing with formatted sequential input statements for which no OPEN statement has been executed. The result is the same as when the BLANK= specifier in an OPEN statement is set to zero. If the x option is omitted, blanks in the input field are treated as null and ignored. The result is the same as if the BLANK= specifier in an OPEN statement is set to NULL or if the BLANK= specifier is omitted.

Example:a.exe /Wl,x

Shell Variables for Input/OutputThis section describes shell variables that control file input/output operations

FUnn = filnameThe FUnn shell variable connects units and files. The value nn is a unit number. The value filename is a file to be connected to unit number nn. The standard input and output files (FU05 and FU06) and error file (FU00) must not be specified.

The following example shows how to connect myfile.dat to unit number 10 prior to the start of execution.

Example:set FU10=myfile.dat

FUnnBF = sizeThe FUnnBF shell variable specifies the size of the input/output work area used by a sequen-tial or direct access input/output statement. The value nn in the FUnnBF shell variable specifies the unit number. The size argument used for sequential access input/output state-



ments is in kilobytes; the size argument used for direct access input/output statements is in records. The size argument must be an integer with a value of 1 or more. A size argument must be specified for every unit number.

If this shell variable and the g option are omitted, the input/output work area size used by sequential access input/output statements defaults to 1 kilobytes. The size argument for direct access input/output statements is the number of Fortran records per block in fixed-block for-mat. The size argument must be an integer from 1 to 32767 that indicates the number of Fortran records per block. If this shell variable and the d option are omitted, the area size is 1K bytes.

Example 1: Sequential Access Input/Output Statements.

When sequential access input/output statements are executed for unit number 10, the state-ments use an input/output work area of 64 kilobytes.

set FU10BF=64

Example 2: Direct Access Input/Output Statements.

When direct access input/output statements are executed for unit number 10, the number of Fortran records included in one block is 50. The input/output work area size is obtained by multiplying 50 by the value specified in the RECL= specifier of the OPEN statement.

set FU10BF=50


C Lahey Technical Support

Lahey Computer Systems takes pride in the relationships we have with our customers. We maintain these relationships by providing quality technical support, an electronic mail (e-mail) system, a website, newsletters, product brochures, and new release announcements. The World Wide website has product patch files, new Lahey product announcements, lists of Lahey-compatible software vendors and information about downloading other Fortran related software. In addition, we listen carefully to your comments and suggestions.

Hours

Lahey’s business hours are7:45 A.M. to 5:00 P.M. Pacific Time Monday - Thursday7:45 A.M. to 12:45 P.M. Pacific Time Friday

Telephone technical support is available8:30 A.M. to 3:30 P.M. Pacific Time Monday - Thursday8:30 A.M. to 12:00 P.M. Pacific Time Friday

We have several ways for you to communicate with us:• TEL: (775) 831-2500 (PRO version only)• FAX: (775) 831-8123• E-MAIL: [email protected]• ADDRESS: 865 Tahoe Blvd.

P.O. Box 6091Incline Village, NV 89450-6091 U.S.A.


Appendix C Lahey Technical Support

Technical Support ServicesLahey provides free technical support on current product releases to registered users. Free support will continue to be available for previous versions of a product for 60 days after the release of a newer version. This support includes assistance in the use of our software and in investigating bug reports. It does not include tutoring in how to program in Fortran or how to use any host operating system.

How Lahey Fixes Bugs Lahey's technical support goal is to make sure you can create working executables using Lahey Fortran. Towards this end, Lahey maintains a bug reporting and prioritized resolution system. We give a bug a priority based on its severity.

The definition of any bug's severity is determined by whether it directly affects your ability to build and execute a program. If a bug keeps you from being able to build or execute your program, it receives the highest priority. If you report a bug that does not keep you from cre-ating a working program, it receives a lower priority. Also, if Lahey can provide a workaround to the bug, it receives a lower priority. Product suggestions are not considered bugs.

If a registered owner of Lahey Fortran reports a bug in the current version (or in the previous version within 60 days following release of a new version), and that bug is verified by Lahey, the bug fix will be made available as a patch or as a free update (at Lahey's discretion) toa newer version of the product containing the bug fix.

Any bug that is reported by any user will be investigated by Lahey only in the latest version of the product.

In recognizing that problems sometimes occur in changing software versions, Lahey allows you to revert to an earlier version of the software until Lahey resolves the problem.

Contacting Lahey To expedite support services, we prefer written or electronic communications via FAX or e-mail. These systems receive higher priority service and minimize the chances for any mis-takes in our communications.

Before contacting Lahey Technical Support, we suggest you do the following to help us pro-cess your report.

• Determine if the problem is specific to code you created. Can you reproduce it using the demo programs we provide?

• If you have another machine available, does the problem occur on it?


Information You Provide

Information You ProvideThe Lahey Tech Support Questionnaire utility can be used to facilitate the gathering of crit-ical information for your support request. It may even help you solve your problem on the spot. It presents a series of dialogs that will guide you to provide the most pertinent informa-tion, generating a file that you can attach to your e-mail to [email protected]. Start it from the LF95 toolbar in Lahey ED Developer, or from the Lahey/Fujitsu Fortran 95 folder in your Programs menu, or run TSQ.

When contacting Lahey, please include or have available the information listed below.

For All Problems1. The Lahey product name, serial, and version numbers.2. A description of the problem to help us duplicate it. Include the exact error message

numbers and/or message text.

For Compiler Problems1. An example of the code that causes the problem. Please make the example as small

as possible to shorten our response time and reduce the chances for any misunderstandings.

2. A copy of the LF95.FIG file (driver configuration file).3. Command-line syntax and any options used for the driver or other tools.

For Other Problems1. The brand and model of your system.2. The type and speed of your CPU.Lahey will respond promptly after we receive your report with either the solution to the prob-lem or a schedule for solving the problem.

Technical Support QuestionnaireThe Lahey Tech Support Questionnaire utility can be used to facilitate the gathering of crit-ical information for your support request. It may even help you solve your problem on the spot. It presents a series of dialogs that will guide you to provide the most pertinent informa-tion, generating a file that you can attach to your e-mail to [email protected]. Start it from the LF95 toolbar in Lahey ED Developer, or from the Lahey/Fujitsu Fortran 95 folder in your Programs menu, or run TSQ.

World Wide WebOur URL is http://www.lahey.com. Visit our website to get the latest information and product patch and fix files and to access other sites of interest to Fortran programmers.



Lahey Warranties

Lahey’s 30 Day Money Back Guarantee Lahey agrees to unconditionally refund to the purchaser the entire purchase price of the prod-uct (including shipping charges up to a maximum of $10.00) within 30 days of the original purchase date.

All refunds require a Lahey Returned Materials Authorization (RMA) number. Lahey must receive the returned product within 15 days of assigning you an RMA number. If you pur-chased your Lahey product through a software dealer, the return must be negotiated through that dealer.

Lahey’s Extended WarrantyLahey agrees to refund to the purchaser the entire purchase price of the product (excluding shipping) at any time subject to the conditions stated below.

All refunds require a Lahey Returned Materials Authorization (RMA) number. Lahey must receive the returned product in good condition within 15 days of assigning you an RMA number.

You may return a LF95 Language System if:

• It is determined not to be a full implementation of the Fortran 90 Standard and Lahey does not fix the deviation from the standard within 60 days of your report.

• Lahey fails to fix a bug with the highest priority within 60 days of verifying your report.

• All returns following the original 30 days of ownership are subject to Lahey’s dis-cretion. If Lahey has provided you with a source code workaround, a compiler patch, a new library, or a reassembled compiler within 60 days of verifying your bug report, the problem is considered by Lahey to be solved and no product return and refund is considered justified.

Return Procedure You must report the reason for the refund request to a Lahey Solutions Representative and receive an RMA number. This RMA number must be clearly visible on the outside of the return shipping carton. Lahey must receive the returned product within 15 days of assigning you an RMA number. You must destroy the following files before returning the product for a refund:

• All copies of Lahey files delivered to you on the software disks and all backup copies.

• All files created by this Lahey Language System.

A signed statement of compliance to the conditions listed above must be included with the returned software. Copy the following example for this statement of compliance:


Return Procedure

I, ________________________________________(your name), in accordance with the terms specified here, acknowledge that I have destroyed all backup copies of and all other files created with the Lahey software. I no longer have in my possession any copies of the returned files or documentation. Any violation of this agreement will bring legal action gov-erned by the laws of the State of Nevada.Signature: Print Name: Company Name: Address:

Telephone: Product: Version: Serial #:RMA Number:Refund Check Payable To:

Return Shipping InstructionsYou must package the software diskettes with the manual and write the RMA number on the outside of the shipping carton. Shipping charges incurred will not be reimbursed. Ship to:

Lahey Computer Systems, Inc.865 Tahoe Blvd.P.O. Box 6091

Incline Village, NV 89450-6091


INDEX

Aa runtime option 195AMEDIT 140-ap option, arithmetic precision 21API, Windows 68AUTOMAKE

$INSERT= 150CHECK= 150COMPILE= 145COMPILEONLY 150configuration file editor 140DEBUG 149FILES= 145KEEPOBJDIR= 148LATESCAN 150LF90 145LIBRARY= 149LINK= 147MAKEMAKE 149NOQUITONERROR 149OBJDIR= 148OBJEXT= 148QUITONERROR 149SCANONLY 149SYSINCLUDE= 148TARGET= 147

B-block, blocksize option 21blocks in ED for Windows 92Borland C++ 45Borland Delphi 45, 63breakpoints 97, 105bugs 202Building Import Libraries 47

CC

Fujitsu C Compiler User’s Guide 9

Fujitsu C help 9C runtime option 194-c, suppress linking option 21case conversion 93

-chk, checking option 22-chkglobal, global checking option 24-co, display compiler options 24code completion 93coding shortcuts 92command files

compiler 14LIB 135

-comment, insert comment into execut-able option 24

compiler 12, 19command files 14controlling 19errors 19

Compiler and Linker Options 20compiler options

description 14compiling from ED for Windows 94-concc, support carriage control charac-

ters in console i/o option 24configuration of ED 100console mode 37-cover, generate coverage information

option 25Coverage Tool 169

-cover option 25help 9

creating a file 88

Dd runtime option 196-dal, deallocate allocatables option 25-dbl, double precision option 25debugger 11Debugging

WinFDB Help 9debugging

from ED 95restrictions 129with FDB 103, 159, 169with WinFDB 129

DEMO.F90 7direct file format 187disassembly 112distribution 8

Lahey/Fu

divide-by-zero 36-dll, create dynamic link library

option 25DLLs 12driver 11dummy argument 185DUMPBIN.EXE 177dynamic link libraries 12

Ee runtime option 196ED for Windows 85, 103, 117, 159,

169blocks 92case conversion 93changing compiler options 94code completion 93coding shortcuts 92compiling 94configuration 100create file 88debugging from 95editing 91exiting 86extended characters 91find 91function/procedure list 90help 88managing files 88matching parentheses and

statements 91menu bar 86, 120navigation 90opening a file 89previous/next procedure 90screen 86set up 85, 117smartype 93starting 85, 117status bar 87templates 92toolbar 87undo and redo 91window bar 88

EDITBIN.EXE 179

jitsu Fortran 95 User’s Guide 207

Index

editing 91editor 11

Lahey ED for Windows 85, 103, 117, 159, 169

efficiency considerations 185environment variables

FORT90L 192FUnn 199FUnnBF 199

ERRATA.TXT 8errors

compiler 19exiting ED for Windows 86extended characters 91

Ff90SQL Lite

help 9-f90sql, link with f90SQL Lite

option 25-f95, standard conformance check-

ing option 25file formats

direct 186formatted sequential 186transparent 186unformatted sequential 186

-file, filename option 26FILELIST.TXT 8filenames 13

extensions 13MOD extension 13object file 13output file 13source file 13

filesERRATA.TXT 8HDRSTRIP.F90 181SEQUNF.F90 182TRYBLK.F90 182UNFSEQ.EXE 182

find text 91-fix, fixed source-form option 26formatted sequential file

format 186FORT90L environment

variable 192Fujitsu 9-fullwarn, detailed linker warnings

option 37

208 Lahey/Fujitsu Fortran 95 Use

function/procedure list 90FUnn environment variable 199FUnnBF environment variable 199

Gg runtime option 196-g, debug option 26

HHDRSTRIP.F90 181Help

Coverage Tool 9ED for Windows 88f90SQL-lite 9Fujitsu C 9Sampler Tool 9Visual Analyzer 9WinFDB debugger 9

hintsdetermining load image size 187efficiency considerations 185file formats 186performance considerations 187side effects 185

Ii runtime option 197-i, include path option 27Import Libraries 47-in, IMPLICIT NONE option 27-info, display informational messages

option 27installation 3invalid operation 36IO_ERROR.TXT 8

LLahey ED for Windows 85, 103, 117,

159, 169Lahey Fortran 90 Reference Manual 9Lahey Fortran 90 User’s Guide 9LFSPLIT.EXE 182-li, Lahey intrinsic procedures

option 27LIB

command files 135response files 135

-libpath, library path option 28librarian 11, 12, 133

librarylinking libraries 40manager 133searching rules 40

limits of operation 189LINK.EXE 12linker 12

library searching rules 39linking libraries 40linking modules 39overview 39undocumented options 39

load image size 187-long, long integers option 28-lst, listing option 28

MM runtime option 194m runtime option 197make utility 11, 139

Automake 139NMAKE 152

MAKEDEF.EXE 182-map, create linker map file option 29matching parentheses and

statements 91-maxfatals, maximum fatal errors

option 29menu bar 86, 120Microsoft Visual Basic 45, 61Microsoft Visual C++ 45, 60-ml, mixed language option 29, 46ML_EXTERNAL 49-mldefault, mixed language default

option 30MOD filename extension 13-mod, module path option 30modules

linking module object files 39

Nn runtime option 198network installation 4NMAKE make utility 152-nologo, suppress linker banner

option 30notational conventions 2

r’s Guide

Index

O-o, object file name option 31-o0, optimization level zero

option 30-o1, optimization level one

option 30object filenames 13office hours 201OpenGL graphics 17opening a file with ED 89Optimization 30Option conflicts 14options

-ap, arithmetic precision 21-block, blocksize 21-c, suppress linking 21-chk, checking 22-chkglobal, global

checking 24-co, display compiler

options 24-concc, support carriage con-

trol characters in console i/o 24

-cover, generate coverage information 25

-dal, deallocate allocatables 25

-dbl, double precision option 25

-f90sql, link with f90SQL Lite 25

-f95, standard conformance checking 25

-file, filename 26-fix, fixed source-form 26-g, debug 26-i, include path 27-in, IMPLICIT NONE 27-info, display informational

messages 27-li, Lahey intrinsic

procedures 27linker

-comment, insert com-ment into executable 24

-dll, create dynamic link library 25

-fullwarn, detailed linker

warnings 37-libpath, library path 28-map, create map file 29-nologo, suppress linker

banner 30-out, output file 31-stack, set stack size 33-staticlib, static or dynamic

runtime libraries 34undocumented 39-warn, publish linker

warnings 37-long, long integers 28-lst, listing 28-maxfatals 29-ml, mixed language 29-mldefault, mixed language

default 30-mod, module path 30-o, object file name 31-o0, optimization level zero 30-o1, optimization level one 30-pause, pause after program

completion 31-pca, protect constant

arguments 31-prefetch, prefetch optimization

option 32-private, module accssiblity 32-quad, quadruple precision 32-sav, SAVE local variables 33-split, create temporary files for

each program unit 33-staticlink, mixed language static

linking 34-stchk, stack overflow

checking 34-swm, suppress warning

messages 35-t4, target 486 35-tp, target Pentium 35-tpp, target Pentium Pro 35-trace, runtime error traceback 35-trap, trap NDP exceptions 36-version, display version info 36-vsw, very simple windows 36-w, publish compiler warnings 36-wide, wide format fixed form

code 37-win, create Windows

Lahey/Fu

application 37-wisk, Winteracter Starter

Kit 37-wo, obsolescent feature

warning 38-xref, cross-reference listing 38-zero, include variables initial-

ized to zero 38-out, output file option 31output filenames 13overflow 36

Pp runtime option 198-pause, pause after program

completion 31-pca, protect constant arguments

option 31preconnected units, standard i/o 193-prefetch, prefetch optimization

option 32previous/next procedure 90-private, module accessibility

option 32program size 189programming hints 185

QQ runtime option 194q runtime option 198-quad, quadruple precision option 32

Rr runtime option 198Re runtime option 195README.TXT 8README_F90SQL.TXT 8README_PORT_56.TXT 8README_PORT_LF90.TXT 8README_SERVICE_ROUTINES.T

XT 8registering 2registers, displaying in WinFDB 126Repairing LF95 6requirements

system 1Resource Compiler 12response files

compiler 14


Index

LIB 135restrictions, debugging 129return codes 15return values, execution 193Rm runtime option 195RTERRMSG.TXT 8runtime options

a 195C 194d 196e 196g 196i 197M 194m 197n 198p 198Q 194q 198r 198Re 195Rm 195Ry 195T 195u 199x 199

runtime options, syntax 194Ry runtime option 195

SSampler Tool 159

help 9-trace switch 35

-sav, SAVE local variables option 33

scrollable window, -vsw option 36

searching ruleslibrary 40

SEQUNF.F90 182setting up ED for Windows 85,

117side effects 185smartype 93source filenames 13Split utility 182-split, create temporary files for

each program unit option 33SSL2 Extended Capabilities

User’s Guide 9


SSL2 Extended Capabilities User’s Guide II 9

SSL2 User’s Guide 9-stack, set stack size option 33standard input/output units 193starting ED for Windows 85, 117static linking 48-staticlib, static or dynamic Linking of

Fortran runtime libraries option 34-staticlink, mixed language static link-

ing option 34status bar 87-stchk, stack overflow checking

option 34step 97, 107step into 97step over 97support services 201switches

changing in ED 94-swm, suppress warning message(s)

option 35syntax highlighting 90SYSEDITS.TXT 8system requirements 1

TT runtime option 195-t4, target 486 option 35technical support 202Technical Support Questionnaire 203templates 92toolbar 87-tp, target Pentium option 35-tpp, target Pentium Pro option 35-trace, runtime error traceback

option 35transparent file format 187-trap, trap NDP exceptions option 36TRYBLK.F90 182

Uu runtime option 199underflow 36undo and redo 91unformatted sequential file

format 186UNFSEQ.EXE 182Uninstalling LF95 6

V-version, display version info 36Visual Analyzer

help 9User’s Guide 9

-vsw, very simple windows option 36

W-w, publish compiler warnings

option 36-warn, publish linker warnings

option 37Warranties 204warranties 204watch dialog 99WHERE.EXE 183-wide, wide format fixed form

code 37-win, create Windows application

option 37-winconsole, Windows console-mode

switch 37window bar 88window, scrolling, -vsw option 36Windows 37Windows API 68Windows console-mode 37WinFDB 117

command line entry 128help 9load map display 127registers display 126restrictions 129traceback display 127watch window 126

WiSKhelp 9Winteracter Starter Kit 9

-wisk, Winteracter Starter Kit option 37

-wo, obsolescent feature warning option 38

World Wide Web 203

Xx runtime option 199-xref, cross-reference listing

option 38

r’s Guide

Index

YY2K compliance, Ry runtime

option 195

Z-zero, include variables initialized

to zero option 38

Lahey/Fu

Index

r’s Guide

lahey/fujitsu fortran 95 user’s guidelahey/fujitsu fortran 95 user’s guide 1 1 getting started...

Documents