ARSC T3E Users' Newsletter 175, August 13, 1999

Stricter CF90 Pre-Processor in PE 3.2

Last month we made a suggestion: when possible, use the Fortran pre-processor on Fortran codes (and save cpp for C/C++). Here's another: watch out out for white space!

In CF90 3.2 the pre-processor requires that no white space exist between a macro name and the left parenthesis beginning its argument list in either macro definition or invocation. This is a behavior change from CF90 3.1 and differs from cpp. (It is documented in the on-line manual--see below.)

Here's an example from the last week's quick-tip. First, the correct version:


      program test
#define MOD(x,y) mod(int(x),int(y))  ! Correct 

      integer*4  int4
      integer*8  int8, res8
      int4 = 4
      int8 = 5

      res8 = MOD(int8, int4)         ! Correct
      print*, res8

      end
CF90 3.2, CF90 3.0, and cpp all handle this as expected. If we run it through "f90 -F -eZ", which says to expand macros in any area of the code and to write the pre-processed code to a ".i" file, we obtain this:

  YUKON$ f90 -F -eZ test.f
  YUKON$ cat test.i
  # 1 "test.f"

      program test

      integer*4  int4
      integer*8  int8, res8
      int4 = 4
      int8 = 5

      res8 = mod(int(int8),int(int4))         ! Correct
      print*, res8

      end

MISTAKE #1:

Adding a space in the macro definition is always a mistake:


  #define MOD (x,y) mod(int(x),int(y))        ! Incorrect 
All of the pre-processors use white space to delimit the name from its definition. Thus, this mistake creates a macro, "MOD," which has no parameters and the unwanted definition, "(x,y) mod(int(x),int(y))". Introducing this error into the sample code and running it through cpp shows the outcome:

  YUKON$ cpp test.f
  #line 1 "test.f"

      program test


      integer*4  int4
      integer*8  int8, res8
      int4 = 4
      int8 = 5

      res8 = (x,y) mod(int(x),int(y))(int8, int4)
      print*, res8

      end
MISTAKE #2:

Adding a space in the macro invocation is a mistake under CF90 3.2:


      res8 = MOD (int8, int4)  ! Incorrect
The pre-processor simply doesn't recognize this as an invocation of the macro. Adding this error to the sample code and running it through the CF90 3.2 pre-processor produces this:

  YUKON$ f90 -F -eP test.f
  YUKON$ cat test.i
  # 1 "test.f"

        program test


        integer*4  int4
        integer*8  int8, res8
        int4 = 4
        int8 = 5

        res8 = MOD (int8, int4)
        print*, res8

        end
Errors in pre-processing can be hard to find. If in doubt, store the pre-processed code in a file and in a separate step, compile that file.

A more rigorous explanation of pre-processor macros follows. This is from the "CF90 Commands and Directives Manual," available from either SGI's techpubs server, http://techpubs.sgi.com/ or ARSC's on-line doc server, http://www.arsc.edu:40/.


> ------------------------------------------------------------------------
> 
>    CF90(TM) Commands and Directives Reference Manual
> 
> ------------------------------------------------------------------------
> 
> Chapter 5. Source Preprocessing
> 
> [ ... ]
> 
> 5.2.2 #define Directive
> 
> The #define directive lets you declare a variable and assign a value to
> the variable. It also allows you to define a function-like macro. This
> directive has the following format:
> 
>   #define identifier value
> 
>   #define identifier(dummy_arg_list) value
> 
> The first format defines an object-like macro (also called a source
> preprocessing variable), and the second defines a function-like macro.
> In the second format, the left parenthesis that begins the
> dummy_arg_list must immediately follow the identifier, with no
> intervening white space.
> 
> identifier                     The name of the variable or macro being
>                                defined.
> 
>                                Rules for Fortran variable names apply;
>                                that is, the name cannot have a leading
>                                underscore character (_). For example,
>                                ORIG is a valid name, but _ORIG is
>                                invalid.
> dummy_arg_list                 A list of dummy argument identifiers.
> value                          The value is a sequence of tokens. The 
>                                value can be continued onto more than
>                                one line using backslash (\)
>                                characters.
> 
> If a preprocessor identifier appears in a subsequent #define directive
> without being the subject of an intervening #undef directive, and the
> value in the second #define directive is different from the value in
> the first #define directive, then the preprocessor issues a warning
> message about the redefinition. The second directive's value is used.
> For more information on the #undef directive, see Section 5.2.3.
> 
> When an object-like macro's identifier is encountered as a token in the
> source file, it is replaced with the value specified in the macro's
> definition. This is referred to as an invocation of the macro.
> 
> The invocation of a function-like macro is more complicated. It
> consists of the macro's identifier, immediately followed by a left
> parenthesis with no intervening white space, then a list of actual
> arguments separated by commas, and finally a terminating right
> parenthesis. There must be the same number of actual arguments in the
> invocation as there are dummy arguments in the #define directive. Each
> actual argument must be balanced in terms of any internal parentheses.
> The invocation is replaced with the value given in the macro's
> definition, with each occurrence of any dummy argument in the
> definition replaced with the corresponding actual argument in the
> invocation.
> 
> For example, the following program prints Hello, world. when compiled
> with the -F option and then run:
> 
>       PROGRAM P
> #define GREETING 'Hello, world.'
>       PRINT *, GREETING
>       END PROGRAM P
> 
> The following program prints Hello, Hello, world. when compiled with
> the -F option and then run:
> 
>       PROGRAM P
> #define GREETING(str1, str2) str1, str1, str2
>       PRINT *, GREETING('Hello, ', 'world.')
>       END PROGRAM P
> 
> [ ... ]
> 

Papers on Performance Evaluation, MPI Collectives

"PEMCS" is the "Journal of Performance Evaluation and Modeling for Computer Systems." PEMCS has several papers on line, including these new postings:

A Frame of Reference for the Performance Evaluation of Asynchronous, Distributed Decision-Making Algorithms, Sumit Ghosh (Arizona State University, USA), Tony Lee (NASA Ames Research Center, USA) and Seong-Soon Joo (Electronics and Telecommunications Research Institute, Korea), July 1999.

And,

The Performance of the MPI Collective Communication Routines for Large Messages on the Cray T3E-600, the Cray Origin2000, and the IBM SP, Glenn R. Luecke, Bruno Raffin and James J. Coyle, Iowa State University, Ames, Iowa, USA, July, 1999.

PEMCS is at:

http://hpc-journals.ecs.soton.ac.uk/PEMCS/Papers/

Fortran's Future: Researcher Requests Responses to Survey

Niki Reid, a PhD student at the University of Belfast, is conducting research into the Fortran language. As part of the project, she requests input from the Fortran community. If you have a chance, please fill out the survey at:

http://www.cs.qub.ac.uk/~N.Reid/

A paper describing the project appeared in the Journal of the ACM Fortran Forum (Vol 18 Number 2), and we've included some excerpts here:
A Prescriptive Semantics of Fortran 95 N. Reid and J.P. Wray School of Computer Science The Queen's University of Belfast Belfast BT7 1NN email: niki.reid@acm.org or jp.wray@qub.ac.uk

This paper outlines current research into a prescriptive semantics of Fortran 95, as a means of investigating the language's strengths and shortcomings. Additionally it is intended that this research will provide a foundation for the application of rigour to Fortran programming.

1. Background

Fortran is a language in flux. While it cannot be doubted that the current dialect, Fortran 95, presents a significant improvement over its predecessor, Fortran 77, some serious shortcomings remain. Given that the current dialect is even now being revised and extended it is imperative that its shortcomings be uncovered to prevent their inclusion in the next generation. Some of the primary objectives for any programming language are [Hoare 1969]: simplicity, readability, machine independence, a large and useful library, existing popularity and sponsorship by a large and powerful organisation.

[ ... ]

4. Fortran Users Survey

To assist the research programme an on-line survey has been developed, from which it is hoped to glean the different uses Fortran is being put to, what type of users predominate, and the types of system in use. Additionally, it is of interest to know what the users perceive as the future of Fortran. On the whole this survey is designed to provide mostly background information, but may have an impact on the direction the research takes. Most questions require only selection of an answer, but comment boxes abound should you wish to make further comment. The greater the response there is to this survey, the more helpful the results will be - please take the time to fill it in!

http://www.cs.qub.ac.uk/~N.Reid/

[ ... ]

We hope to print some results from this research in this newsletter.

Quick-Tip Q & A


A:{{ When I try to submit jobs from yukon, I get the following response:

     c-yukon<666> qsub -q mpp job.script
     NQS local daemon is not present at local host.
     Retry later.

   I've tried several times today and get the same response. What
   should I do? }}



     The program that listens for NQS requests has apparently died and
     needs to be restarted.  Contact the consult desk.



Q: Does any shell available under UNICOS/mk offer file name completion,
   as tcsh does?

[ Answers, questions, and tips graciously accepted. ]


Current Editors:
Ed Kornkven ARSC HPC Specialist ph: 907-450-8669
Kate Hedstrom ARSC Oceanographic Specialist ph: 907-450-8678
Arctic Region Supercomputing Center
University of Alaska Fairbanks
PO Box 756020
Fairbanks AK 99775-6020
E-mail Subscriptions: Archives:
    Back issues of the ASCII e-mail edition of the ARSC T3D/T3E/HPC Users' Newsletter are available by request. Please contact the editors.
Back to Top