gotoHomeFree Source CodePortability ProjectFact SheetEmail us |
Purple Sage Computing Solutions, Inc. |
|
make_processor_model Namelist Input File Home --> Fact Sheet --> Free Source Code --> Portability Project --> make_processor_model input About make_processor_model's Namelist Input FileSince a Fortran 95 program can't diagnose entirely the processor where it runs, some other source of information must be found. For make_processor_model, that other source is an input file. To keep things as simple as possible, namelist format is used. If you choose to make a file for use with a conditional compilation preprocessor, the definitions in that file will match those in standard_types. There are six namelist groups. They cover the filenames used by make_processor_model, and the hardware and software specifics of the processor. Below, each namelist group is discussed in turn, the variables in each group are listed together with their default values. The basic recipe here is to RTFM and fill in the namelist variables for your compiler and needs. The next section describes the namelist input file, and is formatted as follows:
Further commentary follows the list below. The namelist groups which may be read from make_pm.in, their variables, default values and some comments are listed:
Commentary (and a Few Tips)In general: The namelist groups may appear in any order, the input file is read repeatedly from the beginning. As always with namelist, if you want to leave a variable's value as-is, you may simply omit the variable. Hopefully, this makes for an easy-to-use input file. Group files: The name of the namelist input file is fixed (unless you change the make_processor_model source code) as "make_pm.in". The name of the logfile is fixed as "make_pm.log". If all goes well, make_pm.in is minimal and make_pm.log contains no WARNINGS. Any warning in the logfile should be understood; it may mean that make_processor_model is inaccurately analyzing your processor. The logfile has a time stamp which helps out when several runs have been made. The variable incname specifies an include file which is written by make_processor_model; it may be included by a preprocessor with the rest of a Fortran program. The include file has a preprocessor variable set for each kind present with a usable definition in standard_types. This way, you can control the conditional compilation to match the contents of standard_types. Set incname to "coco.inc" for a Fortran standard coco include file format, set incname to "f90ppr.inc" for use with Michel Olagnon's f90ppr, set incname to "fpp.inc" for use with the traditional fpp or cpp style preprocessor. Group hw: The hardware group should require no input for most processors. The analysis will assume a byte addressable processor if it can detect a consistent size of bytes. For word addressable processors simply leave the bytesize at 0 if you want to automatically detect how large a byte is, (e.i., if the analysis is not detecting how characters are packed within a word). Leave the integer wordsize 0 if you have a byte addressable processor, set it to the number of bits in a word if you have a word addressable processor (and set bytesize to reflect the character packing). Group sw: The group most likely to warrant input is the software group, as here is where you'll define your compiler's name, its serial number, and the name and version of the operating system you're using. To get your compiler's name and version: if you're using a Unix system, try f90 -V or f90 -version; if you're using Windows or MacOS, try Help|About in the IDE. Also, some processors may have a stderr file available (possibly unit=0). If you don't have a stderr file, just leave stderr set to -1 and make_processor_model will equate stderr to the unit set for stdout (so error messages always have somewhere to go). The logical f2kcli may be set to true if you are using the f2kcli (Fortran 2003 Command Line Interface). This will add some diagnostic constants and functions to standard_types. It has no effect if you have a Fortran 2003 compiler. About standards: The std string may be "f90", "f95" or "f03"; if it's "f95" or "f03", pure procedures will be declared with the pure attribute. Setting std to "f90" also causes a cpu_time() intrinsic to be written to standard_types for processors which don't have a cpu_time() intrinsic to avoid link errors. This cpu_time() intrinsic merely returns a negative value signalling that it doesn't work. Of course, you may customize it with your f90 processor's cpu time call. This way, you can hide the non-standard time functionality inside the cpu_time() routine. If your f90 processor has a cpu_time() intrinsic, you should set cputime to true so make_processor_model won't add its own cpu_time(). (cputime has no effect if std is "f95" or "f03", they're supposed to have one.) If std is "f03", then the intrinsic module iso_fortran_env is available as a part of your processor, it is used in processor_model, and the values defined therein are not written to standard_types (to avoid redundant definitions). (In the current draft standard, iso_fortran_env defines input_unit, output_unit, error_unit, iostat_eor and iostat_eof.) If you are using the f2kcli module, you should set the logical f2kcli to true, this variable has no effect if the std is set to f03 (since you're assumed to have the f03 command line interface in that case). Also, if std is set to f03, the C special character constants are not written to standard_types, they may be found in the ISO_C_BINDING intrinsic module. About kinds: The preprocessor include file's definitions always match the definitions in standard_types. When using standard_types, if you don't like the name chosen for a kind parameter, at worst you can rename it on the use statement. You may, of course, use max and min etc. functions to further compute which kind you want. Unfortunately, these capabilities aren't available with coco. Group kinds: The kinds group needs no input if you have ascii characters as kind=1, and don't want to define logical kinds. If you do want logical kinds defined, set the appropriate variable equal to the kind value for the desired kind parameter. Or set logeqint to true, this will make a logical kind for every integer kind discovered. It ignores any of the log??? variables (so that l_byte_k has the same value as byte_k regardless of the value of logbyte, etc.). The built-in rules will assume that a logical kind has the same storage requirements as an integer of the same name (i.e., that logical kind l_int_k requires the same storage as integer kind int_k, etc.). Set the logical strings to true if you are using the ISO_VARYING_STRINGS type, leave it false otherwise. Group float: The easiest thing to do here is to leave the logical autoreal set to true (its default value) and let the program diagnose your processor. Otherwise, the float group defaults to IEEE singles and doubles, and for "IEEE" quads. To manually make a Cray PVP have kind=double_k for its 64 bit reals, simply set the dp to 14 rather than 15. If you are controlling the real search manually and you have the "extended quad" kind, you'll have to adjust the qr variable (try qr=290). The logical autoreal is .true. by default, which causes an automatic search for real kinds. If you prefer to set the precision and/or range of your real kinds yourself, set autoreal to .false. The search is made by precision; searching by range is unreliable. A warning will appear in the logfile if a real kind can't be matched with a name. This may occur if your compiler supports the Intel 10 byte register real. Group fixed: The easiest thing to do here is to leave the logical autoint set to true (its default value) and let the program diagnose your processor. Otherwise, the fixed group defaults to two's compliment one byte, two byte, four byte and eight byte integers. If this doesn't match your processor and you want to control the integer search manually, you'll need to fix things here. The logical autoint is .true. by default, which causes an automatic search for integer kinds. If you prefer to set the digits of your integers yourself, set autoint to .false. A warning will appear in the logfile if an integer kind can't be matched with a name. Of course, if you have any questions or comments, please E-mail us and we'll try to reply, or at least provide more information. |
|
| Home - Fact Sheet - Free Source Code - Fortran Links - Email us |