This paper gives details of the differences between the various implementations of FORTRAN, and the facilities offered by the loaders on the machines proposed for the Interactive Engineering Facility. The ICL machine considered is the 1906A, although recent events suggest a 2980 should be added. Unfortunately, insufficient evidence is available to give much of a comparison.
The FORTRAN section includes the results of two benchmarks. One set or three programs gives an indication of the type of code produced by the compilers. The other program gives an indication of how errors are handled.
This chapter deals with the extensions that are available in the various machine dialects. It serves to emphasise the diversity of these additions - in some cases, the same syntax has been used to mean different things.
It is possible to consider some extensions in two ways. They increase the features available to the FORTRAN programmer, giving him more freedom of action. However, if there is any chance that the program will be transferred to another machine, the inconvenient use of these extensions causes considerable problems. This is particularly true when some standard restrictions are relaxed. in this case, it is extremely useful to have a compiler option which will indicate deviations from the standard and also to have a manual which provides this information.
Comments are made under various type headings, giving details of compiler variations. There is also a section on the type of manuals provided. The language versions considered are:
All the manuals are designed as reference manuals, with separate chapters on various sections of the language. The DEC and CDC manuals explicitly describe the online use of the language. Both give clear indications of where their versions differ from standard ANSI FORTRAN (although DEC is not completely accurate on this) and ICL gives an appendix listing the differences, Univac and Burroughs give no such indication.
DEC and Univac give sections on how to program, with hints on pitfall avoidance.
CDC provide a considerable number of program samples.
Univac allow lower case.
DEC allow a wider range of extra characters.
CDC allow ≠ for '.
DEC and Burroughs allow more than one statement on a line, separated by ;. CDC also allow this, but use $ as separator.
DEC have a special online free format syntax, allowing tab to skip to column 6 or 7. if used, only digits are allowed to indicate continuation.
Comment lines may be indicated by $ or * (CDC) or $, *, / or ! (DEC). Burroughs and DEC allow in-line comments (% and ! respectively).
Both CDC and DEC have special debug lines. DEC has normal FORTRAN statements with D in column 1, which can optionally be compiled.
ICL allows 32 character names. Burroughs allows 31 dimensional arrays while UNIVAC and ICL allow 7. DEC has no limit and CDC 3.
CDC have debug control statements indicated by C$.
CDC specify listing directives by C/. Burroughs use $ for compiler control words.
The following table shows the type and accuracy of the constants available (number of digits or characters). Hex constants are indicated by Zn. Octal constants are indicated by On (Burroughs, Univac), nB (CDC) and "n (DEC) ICL only allow Hollerith constants in data initialisation, or parameters. The following table indicates the precision of constants.
CDC | Burroughs | Univac | ICL | DEC | |
---|---|---|---|---|---|
Integer | 18 | 12 | 11 | 7 | 11 |
Real | 15 | 11 | 9 | 11 | 8 |
Double Real | 29 | 22 | 18 | 20 | 18 |
Octal | 20 | 16 | 12 | 12/24 | |
Hexadecimal | 12 | ||||
Hollerith | 10 | 264 | Yes | Yes | 5 |
All compilers allow Complex and Logical constants. CDC and Burroughs allow .T. as an abbreviation for .TRUE.
The following table gives details of number of characters in a variable name, type of array subscript and maximum number of dimensions.
CDC | Burroughs | Univac | ICL | DEC | |
---|---|---|---|---|---|
Names | 7 | Truncated to 6 | 6 | 32 | Truncated to 6 |
Type of subscript | Arithmetic expression | Arithmetic expression, including -re | Arithmetic expression | Integer expression | Arithmetic expression |
Maximum Dimension | 3 | 31 | 7 | 7 | No limit |
CDC allow masking expressions, which involve using logical operators .AND. etc on non-logical variables.
CDC also allow full set of relational expressions with COMPLEX data types. DEC allow relation only for .EW. and .NE.
DEC allow + for exponentiation, and have defined .XOR. and .EQV. Sign is used to indicate true or false, and arithmetic expressions can be included in logical operations. < > and = are allowed.
Burroughs have defined .IS. for identity. There is also a VALUE construct, used in I/O type control.
Univac use character expressions as a special type. Strings may be concatenated with &. Logical operations on non-logical variables are performed by typeless functions.
ICL, UNIVAC and CDC a1low multiple assignment statements. The first two use commas, while CDC repeatedly uses equals.
Univac allow character assignments, and CDC allows masking assignments.
This section is separated into the individual control statements, since there is a considerable amount of diversity.
Control variable out of range causes a fatal error in CDC, while all the others allow control to pass to the next statement.
The comma may be omitted in CDC, Burroughs and Univac, but should be included in ICL and omitted in DEC.
CDC and DEC allow expressions in place of the variable.
Univac allow blank labels to indicate the next statement.
CDC, Burroughs and Univac allow the comma to he omitted. All except CDC allow the label list to be omitted. Univac allow blank labels.
CDC allows a two-branch arithmetic IF. Univac allows blank labels.
CDC allows a two-branch logical IF.
Univac allow an optional comma before the equals.
DEC allow any expression as a parameter (including negative), which will be truncated to integer.
ICL and Univac allow integer (positive) expressions as parameters.
CDC allow octal parameters.
Burroughs allow real parameters and real Control variable. the parameters can be altered from within the loop.
RETURN x
where x is:
All allow an IMPLICIT declaration to define data type.
ICL, Burroughs and Univac allow data initialisation in a type specification. In addition, Univac allow this in a dimension statement.
DEC allow minimum and maximum values of array dimensions to be given.
CDC allow numbered COMMON blocks.
Univac have a type CHARACTER. An optional l is allowed in EXTERNAL.
DEC and Univac (and ICL) allow source to be included from elsewhere. Univac (and ICL) allows various editing to occur as well.
CDC and Univac have statements to specify where data is to be placed in store (LEVEL and BANK respectively).
Univac allow names to be given to constants (PARAMETER).
CDC and ICL require a statement to head a main program (PROGRAM and MASTER).
All allow label passing to subroutines. In each case except for CDC, this is indicated by a * in the dummy argument list. ICL and Burroughs use & label in the subroutine CALL, DEC uses $ label, and Univac allows either.
CDC use a separate RETURNS list on subroutine statement and CALL.
Multiple entry points are allowed. No argument list is allowed with CDC (assumed to be the same as that on the main routine).
Burroughs allow recursion.
Univac require a DEFINE for statement functions.
There is a considerable variety in type and scope of the intrinsic functions available.
This will be divided into various subsections.
All have a namelist feature. CDC and DEC use $ name at the head of the list, and $ at the tail. ICL and Burroughs allow & name at the head and &END at the end. Univac allows either.
CDC, DEC and Univac indicate this by * in place of the format statement number. CDC Minnesota FORTRAN omits the statement number, and allows layout variation by access to a special COMMON block.
Burroughs use / for input, and have various options for output.
ICL use FORMAT types with zero field width.
CDC, DEC and Univac use ENCODE, DECODE.
ICL use DEFBUF to associate an array.
Burroughs allow an array name in place of unit number.
There is a considerable diversity on how files are handled. Burroughs have a set of OPEN, CLOSE routines. DEC allows file names to be provided interactively at run time.
A specific record in a random file is identified by 'R (ICL, Univac), #R (DEC) or =R (Burroughs).
All except CDC allow action on end of file or data error. CDC Minnesota FORTRAN does allow action on end of file or data error by the unusual form .END. =, .ERR. =.
All allow PUNCH and PRINT. DEC have ACCEPT, TYPE for terminal I/O, and also allow REREAD.
Burroughs allow expressions in I/O lists. It is possible to obtain status information about any transfer, and to get information on the connected device type.
CDC Minnesota FORTRAN has an unusual in-line form of PRINT.
CDC allow the format to control the conversion required. ICL insist that the I/O list and the format correspond. Burroughs allow differences to be trapped.
The following unusual facilities are provided:
CDC and Burroughs allow variable field widths, where the value is taken from the I/O list (= and * respectively).
CDC provides a compiler option to test for variations from the ANSI standard. This is of great assistance when transferring programs between different machines.
No direct details of optimisation are available. However, it would appear that ICL is able to recognise common sub-expressions across statement boundaries, can take code out of DO loops and make use of its accumulators. It will generate simple DO parameter loops only in certain special cases, however. It is possible to request that functions with side effects be left in their proper place.
No direct details are available.
The optimiser attempts the following:
It is noted that certain assumptions made by the optimiser may cause worse, or even erroneous code; for example:
Burroughs allow optimisation levels -1, 0 and 1. 0 is the default. Optimisation levels can be changed from one routine to another. The general features are:
There are three optimisation levels:
In addition, there is an unsafe addition to option 2, involving:
DEC | Univac | Burroughs | CDC | |
---|---|---|---|---|
Character Set | 1 | 2 | 4 | 3 |
Manuals | 2 | 3 | 4 | 1 |
Size of Reals | 4 | 3 | 2 | 1 |
Size of Octals | 3 | 4 | 2 | 1 |
No of Dimensions | 1 | 3 | 2 | 4 |
Format extensions | 4 | 3 | 1 | 2 |
DEBUG | 1 | 2 | 3 | 3 |
DO parameters | 2 | 3 | 1 | 4 |
DEC | Univac | Burroughs | CDC | |
---|---|---|---|---|
ANSI switch | Yes | |||
Multi-statement | Yes | Yes | Yes | |
Free Format Source | Yes | |||
Inline comment | Yes | Yes | ||
Hexadecimal | Yes | |||
MASKING | Yes | |||
Extra Relationals | Yes | Yes | ||
CHARACTER | Yes | |||
No need of PROGRAM statement | Yes | Yes | Yes | |
Multiple assigns | Yes | Yes | ||
Recursion | Yes | |||
GOTO Expression | Yes | Yes | ||
Blank Labels | Yes | |||
Variable field width | Yes | Yes | ||
2 branch IF | Yes | |||
Source inclusion | Yes | Yes |
No of Continuations | 20 | infinite | infinite | 20 |
Variable Names | 6 | 6 | 6 | 7 |
PUNCH, PRINT | Yes | Yes | Yes | Yes |
TYPE | Yes | |||
Max Statement No | 99999 | 32767 | 99999 | 99999 |
Decimal Precision | -38 to 38 | -38 t0 38 | -47 to 68 | -293 to 322 |
ACCEPT | Yes | |||
END FILE | Yes | Yes | ||
Integer max | 11 digs | 11 digs | 12 digs | 18 digs |
Literal transfer | Yes ' ' | Yes ' ' | Yes " " | Yes * * |
Max A field | 5 [10] | 6 | 6 | 10 |
Subscript, general | Yes | Yes | ||
Subscript, integer exp | Yes | Yes | Yes | Yes |
Dimension | infinite | 7 | infinite | 3 |
External Switch | Yes | Yes | ||
OVERFL | Yes | |||
COTAN | Yes | |||
SINH | Yes | Yes | Yes | |
Double Precision | 16 digs | 18 digs | 23 digs | 29 digs |
IMPLICIT logical | Yes | Yes |
Machines Considered:
This table is included for interest only. Any differences with the previous data are due to the early date of this survey.
The program has been constructed to tryout a number of syntax error, extensions and unusual features. It is of interest in that it highlights the differences between the various compilers in their attitude to the unusual.
General comments:
0001 C THIS IS A COMMENT 0002 0INTEGER FUNC TION XF(YP) 0003 COMMON / YP / Q, NQ // Z(4) /COM/ COMX 0004 COMMON / YP / MORE 0005 C** 0006 1 0 DIMENSION S(12),FORMAT(8),Q(NQ) 0007 DIMENSION COMPLEX(1,1,1,1,1,1,1), ZPLUS4(1,8) 0008 C 0009 EQUIVALENCE (ZPLUS4(1),Z(1),NV,V) 0010 B(I)=S(I) 0011 +*1. 0012 DATA PB / 1H / 0013 COM(X) = (1.0) 0014 C(J) = FLOAT(J) + 9.0 0015 60 TAN(X) = SIN(X) / COS(X) 0016 C## 0017 ZPLUS 4(2,1) = 99999. 0018 X = 0.0 0019 WRITE(6,100 ) 0020 1000 FORMAT(//2X,A1,(3(/2 H )))) 0021 TOT = 0 0022 RV = PB 0023 NV = 0 0024 C 0025 DO 1 I = 2.4 0026 DATA FORMAT / 8*0.0 / 0027 1 TOT = TOT + FORMAT(I) 0028 I = 1 0029 IF(YF.NE.(YF*YF)/YF) GOTO 9 0030 C 0031 IF(YF * * 2. * * 1. GT .-1. 0E - 4) GO TO 07 0032 N = NFUNC('9') - NFUNC(1H9) 0033 IF((3. LT ..4)) IF ( 3.-.4) 1,2,3 0034 Y = SIGN(XF(0.0),X) 0035 DO 10 L = 1,90 0036 10 IF(L.EQ.90) CONTINUE 0037 C 0038 FORMAT(3X) 0039 C 0040 DO 2 I = 1,10 0041 ASSIGN 4 TO L 0042 ASSIGN 3 TO K 0043 K = J 0044 IF (I.GT.5) K = L 0045 DATA A / 10H1234567890 / 0046 GOTO K 0047 3 CONTINUE 0048 CONTINUE 0049 DO 2 K = 1,9 0050 6 IF((VP)) 2,2,6 0051 2 CONTINUE 0052 GOTO 6 0053 C== 0054 4 I = -6/(-4)+3+MIN0(2,3)*-1 0055 GOTO (1,1,1,1),I 0056 GOTO 0009 0057 C 0058 000 9 JUNK = JUNK + NINTF(27,1234567890987654321) 0059 7 V= 0060 7+0 0061 WRITE(6,10) NV 0062 READ(5,200) B(I) 0063 READ5,200) T,FORMAT,((N,M), J=1,1,1) 0064 200 FORMAT(I2/(A4/)) 0065 WRITE(6,2)(VP),((10),I+1,(9) 0066 2 FORMAT(F10,6) 0067 ENDFILE 6 0068 FORMAT (1*1*1) =0.0 0069 PAUSE 777 0070 0E N D
The table below shows the number of errors detected by the various compilers.
Compiler | Errors | Warnings | Comments |
---|---|---|---|
ICL XFEH | 10 | 9 | |
ICLXFIH | 8 | 9 | |
DEC FOR | 13 | 1 | |
DEC F40 | 11 | ||
Univac FOR | 14 | 10 | |
Burroughs FORTRAN | 10 | 7 | |
CDC Minnesota MNF | 12 | 48 | 5 |
CDC FORTRAN | 12 | 5 |
The following is a detailed review of these errors
Errors are listed at the end of the program in a somewhat random order. No symbol maps are available.
The debugging compiler XFIH found fewer errors than the production compiler XFEH.
Error lines from the FOR compiler are buried in the text, and are difficult to disentangle. True errors are flagged by ?FTN, while comments are flagged by %FTN and the distinction is sometimes hidden. The error on line 6 was not recorded until the end of the routine.
F40 marks its errors in the text very clearly, with pointers above and below. Statements are not numbered. It is possible to obtain a full list of symbols and constants.
Errors are flagged in the code, and are reasonably clear. They tend to occur before the line in error, but this is not always the case (duplicate label error occurs after the line).
Errors appear inline, and are quite clear. Statements are not numbered. However, the pointer system (indicating where in the line the error was detected) sometimes points to strange places. Some attempt is made to include the section of code in error in the message itself, but this can be misleading, End of line is signalled by ; which does not occur explicitly.
A number of loader errors are also flagged, such as no main program, unavailable functions.
The Minnesota Fortran MNF is used at Imperial in preference to CDC standard, as the debugging compiler. Messages are given inline. Fatal errors are marked on the right-hand-side of the listing. A considerable number of warnings and comments are generated. Some of these are very helpful (such as undefined variable use. and possible mispunch), but others are misleading (particularly those associated with functions that might be in the system library).
The standard CDC compiler provides errors at the end. These are not particularly clear, and the fact that the source is listed with line numbers at every 5 statements does not help. Two unusual errors were generated at the end, but their meaning is unclear.
Three of the programs (IF, GAMMA and BESSEL), used in the Bryant and Baylis FORTRAN evaluation study, 1968, were run on the compilers, at normal and optional levels of optimisation. The word lengths of the various machines are:
Burroughs use a byte instruction system, geared to stack manipulation, and, although the number of orders generated is greater than the others, the number of bits used is comparable. CDC use a mixture of 15 bit (register) and 30 bit orders.
ICL produce two FORTRAN compilers, one for optimisation and one for compiling and testing. XFEH was used here (the optimiser under GEORGE 4). There is no compiler option to list the code, so it is necessary to load the routine and dump the core to find out what has been compiled. There is therefore no assistance given in matching FORTRAN statements to the code produced.
Two compilers were considered. F40 and FORTRAN V (FOR). The latter had an optimising option.
F40 produced the code listing at the end of the source, giving corresponding FORTRAN source statement number. Generated labels bore some resemblance to the FORTRAN equivalents.
FOR produced code between the FORTRAN statement listings if unoptimised, or at the end if optimised. However, it was usually the case that the next FORTRAN statement was listed before the whole of the code for the previous statement had been produced.
Here again there were two compilers. FOR produced inline listings, whi1e FTN listed the code after the source, together with corresponding statement number. Labels were related to the FORTRAN equivalents.
The Burroughs compiler produces listings in line when unoptimised, and after the source is optimised. The optimised listing does attempt to relate to statements, but the reordering is so drastic that it is very difficult to discover which orders have been produced by which statement.
The CDC compiler with OPT=0 produces code at the end of the listing, interspersed with FORTRAN statement numbers. FORTRANI labels are also retained. The code with OPT=2 is much more sorted, since registers are used when possible, and FORTRAN statement numbers appear occasionally in the listing, giving some help in finding how the code has been generated.
The mixed order lengths (15 and 30 bit) mean that occasionally space is wasted at the end of a word.
This artificial routine is designed to determine what code is generated for IF statements. In fact, as a routine, it achieves nothing but the Burroughs optimiser was the only compiler to recognise the fact!
This is a rather moderately written program to calculate Gamma functions. It does allow machines with a full order set to take some advantage, particularly on constant loading and store incrementing.
This routine computes BESSEL functions. It uses single subscripting extensively, with some constant subscripts and private arrays.
These tables show the order of the compilers when the total numbers of words, bits and instructions are considered.
Bessel | |||||
---|---|---|---|---|---|
Words | Instructions | Bits | |||
Burroughs Opt | 136 | DEC FOR | 246 | Burroughs Opt | 6528 |
Burroughs Unopt | 193 | DEC F40 | 250 | DEC FOR | 8856 |
DEC FOR | 246 | Univac FTN | 267 | DEC F40 | 9000 |
DEC F40 | 250 | Univac FOR | 291 | Burroughs Unopt | 9264 |
Univac FTN | 267 | ICL XFEW | 389 | ICL XFEW | 9336 |
Univac FOR | 291 | Burroughs Opt | 575 | Univac FTN | 9612 |
ICL XFEW | 389 | Burroughs Unopt | 616 | Univac FOR | 10476 |
Gamma | |||||
Words | Instructions | Bits | |||
Burroughs Opt | 49 | DEC FOR Unopt | 88 | Burroughs Opt | 2352 |
CDC Opt | 75 | DEC FOR Opt | 90 | ICL XFEW | 3169 |
DEC FOR Unopt | 88 | DEC F40 | 96 | DEC FOR Unopt | 3168 |
CDC Unopt | 90 | Univac FTN | 99 | DEC FOR Opt | 3240 |
DEC FOR Opt | 90 | CDC Opt | 104 | DEC F40 | 3456 |
DEC F40 | 96 | Univac FOR | 110 | Univac FTN | 3564 |
Univac FTN | 99 | CDC Unopt | 128 | Univac FOR | 3960 |
Burroughs Unopt | 100 | ICL XFEW | 132 | CDC Opt | 4500 |
Univac FOR | 110 | Burroughs Opt | 239 | Burroughs Unopt | 4800 |
IXL XFEW | 132 | Burroughs Unopt | 239 | CDC Unopt | 5400 |
IF | |||||
Words | Instructions | Bits | |||
Burroughs Opt | 5 | Burroughs Opt | 24 | Burroughs Opt | 240 |
CDC Opt | 46 | DEC FOR | 77 | ICL XFEW | 2040 |
Burroughs Unopt | 52 | Univac FTN Opt | 83 | Burroughs Unopt | 2496 |
CDC Unopt | 53 | ICL XFEW | 85 | CDC Opt | 2760 |
DEC FOR | 77 | DEC F40 | 86 | DEC FOR | 2772 |
Univac FTN Opt | 83 | CDC Opt | 87 | Univac FTN Opt | 2988 |
ICL XFEW | 85 | Univac FOR | 91 | DEC F40 | 3096 |
DEC F40 | 86 | Univac FTN Unopt | 98 | CDC Unopt | 3180 |
Univac FOR | 91 | CDC Unopt | 104 | Univac FOR | 3276 |
Univac FTN Unopt | 98 | Burroughs Unopt | 170 | Univac FTN Unopt | 3528 |
In general, the compilers all seem to produce reasonable code. ICL are hindered by the poor addressing, and by the shortage of jump orders. DEC do n make use of their full set of orders. The optimiser got very l little extra out of these routines. Univac optimisation is good, but again they are hampered by the shortage of jump orders. Their order code did however allow the inline production of code for some of the intrinsic functions. Burroughs was the only compiler to produce completely unoptimised code as standard, but even so tended to use about the same number of bits as the other compilers. The optimiser made great savings by reordering the stack and preloading variables to appear at the top at the right time. CDC produced an almost unoptimised version as standard, and also seemed to make good savings by recognising loop structures whenever they occurred and using registers therein. There was also an attempt to maximise instruction overlap,
This is a brief description of the programs available to assist in debugging a running program.
There are no special debug aids available.
The FORDDT system allows interactive debugging of a FORTRAN program. The user can:
In addition, DEC allow debug insert lines, signalled by D in column 1, which will be compiled only if the correct compiler option is set.
The FORTRAN checkout mode can be detected by the C and Z options. This allows the user to trace execution, halt and dump variables. Checkout can be entered after a program has started execution. No optimisation is possible. A maximum of 8 break points are allowed.
Various DEBUG statements can be inserted into the source, and compiled only if the correct compiler option is set. These are special statements:
The compiler has subroutines to dump memory in octal, real or integer form, and to trace subroutine calls.
There is also a debug option to check array bounds, assigned GOTO, subroutine calls, function values, program flow and values stored. No optimisation is possible. Debug statements are signalled by C$ in the code. Variables can be listed when they become greater, less than or equal to a constant.
These are called consolidators. They link in library routines and produce binary modules either in core or saved on file.
Libraries can be stored in one of three formats: direct compiler output, linked list or compact. The last two are generated by separate utilities; the linked list is the only updateable version, but is slow to scan, while the compacted version is normally obtained from this linked list. Nottingham University have produced a separate library builder.
Libraries are scanned in order. Routine order must be arranged correctly by the user. However, the Nottingham system does provide an automatic ordering scheme.
Overlays are only available under the non-paged consolidator. They are defined as a level structure, with many available levels. Overlays must be called in by the routines themselves, but FORTRAN generates the necessary calls by compiler switch.
The consolidator provides a map of the symbols, together with their location. In the non-paged version, the overlay level and segment numbers are given, but there is no ordering of the symbols. No cross referencing or overlay structure maps are provided.
This is called the Link Loader. It can be run either automatically by LOAD, EXECUTE or DEBUG, or by a specific call. In the latter case, more facilities are available.
The automatic mode is driven by file extension. It is possible to request versions of the loader from different directories.
Two versions are available., LINK-10 and LOADER. The first has more features.
Libraries are scanned in the order specified. A utility, FUDGE2, allows for their creation and updating. In direct mode, very extensive facilities are provided, some of which are interactive. It is possible to specify different libraries at different points in the load process. Symbols may also be defined at a terminal. The user can set his own defaults, and Local symbols can be saved for use by DDT later.
An overlay tree structure is provided. The whole path to a node must be in core for that node to be accessible. Routines are loaded automatically when referenced.
A utility program will give the order of cal1ing sequences among components, and this can be used to set up the structure. The dynamic structure must be obtained by analysis (the log file will give some help here).
The overlays are held in two files - one containing the root, and the other the rest of the structure. This second file must be contiguous.
A comprehensive set of output is available to the user. At any point in the loading, a list of undefined symbols can be obtained. A symbol file can be generated and sorted. It is possible to get a graphic representation of the overlay structure.
COMMON blocks must be loaded explicitly, with the largest block first.
There is a test mode for entering debug.
Core is divided into low and high. Each is saved in a separate file.
Sharable code can be generated.
This operation is called Collection. The Collector sets up the bank structure, and also prepares files.
Library files are scanned in order. Routines are grouped as elements in these files. It is possible to exclude elements, and to set undefined symbols by parameter.
A PREP parameter will obtain a symbol table for a file, which may then be used as a library. Compiler output is sent to an element, so files may be extended. I cannot find details of file ordering procedure.
This is done by defining segments. The start address of a segment can be determined in a number of ways, including highest of a set of routines. They can be loaded implicitly or explicitly. Dynamic segments are not included in the program initial core requ1rcments.
However, there is also a system of banks, independent of segments. Instructions and data are separated into I-banks and D-hanks, and there can be multiple banks. Segments can lie within a bank, or cross bank boundaries.
There are multiple location counters, which can be assigned to different banks.
Two listing levels are available. The fullest provides details of the symbol table, external references of each element and a scale drawing of the program segmentation and bank structure. It is possible to provide a diagnostic for addresses above 65K, or to allow them.
Maximum I-bank size is 65K.
Re-entrant code can be produced.
Output can be absolute or relocatable.
There are a number of debug aids available, including a flow analysis program for frequency and timing (FLAP), and a debug package, SNOOPY, with breakpoints but no symbols. A SNAP directive allows snapshots.
The FORM directive allows easy duplication of a previously specified program structure.
This is the System Binder. Normally, routines are compiled into segments which will automatically be brought down when necessary by the operating system.
Library routines require to be at the correct lexicographic level for calls to be correctly satisfied. This is no problem in FORTRAN where all routines are at the same level. A main program (host) is bound together with its subroutines. New subroutines and replacements cab be bound with the previous collection, so a separate library facility is not used. However, system libraries can be built using the Intrinsic Binding feature, which does not need a host. Whole files or specific routines may be bound, or files scanned to satisfy references. The LIBRARY option on a compiler allows more than one subroutine per segment. References can be renamed. Intrinsic Binding is not available to FORTRAN routines.
No overlay system is provided. Since the whole concept of the machine is to use separate segments, there is an automatic structure imposed, which requires only active segments to be present.
Listing output options include a list of input cards, identifiers, segment dictionary changes (when binding new routines to an already bound program), and address couples of the identifiers. A hexadecimal dump of the object code is available, and error messages can be sent to a separate file for CANDE. There is even a TRACE option to debug the Binder itself!
Warning messages can be issued if the possibility of an error exists.
It is better to bind new routines to a bound set, rather than rebind the lot again.
The loader takes its commands from the JCL stream, and generates temporary files with reserved file names. The loader can be called in by program, setting up his own request table.
Libraries can be generated and maintained by NOS commands. Libraries can be defined as global to the whole process) or local. Libraries are searched circularly, so there is no internal ordering required. It is possible to force the loading of a library item, and to handle multiple libraries, Names can be altered at load time.
There are three levels into which routines can be overlaid. One level is the base, the second level can have 64 sections, and the third level allows 64 sections for each second-level section. Overlays must be called explicitly from the program.
A more general tree-structured segmented system may become available.
Load maps can be sent to file. Cross reference listings are available, together with statistics and entry point maps.
There is a TRAP option to allow a certain amount of debugging. This includes snapshots, and values of locations within a given range.
The ranking of the various FORTRAN compilers is difficult since it depends on so many conflicting features. This is also true of the loading facilities, since they are all organised differently.
The following is an attempt at a (very personal) ranking (omitting ICL). The double figures in the clarity of message row refer to different compilers.
CDC | DEC | Burroughs | Univac | |
---|---|---|---|---|
FORTRAN features | 1 | 1 | 3 | 4 |
Number of errors found | 4 1 | 3 | 5 | 1 |
Clarity of error messages | 5 3 | 5 1 | 2 | 4 |
Number of words compiled | 2 | 3 | 1 | 3 |
Number of bits compiled | 4 | 2 | 1 | 2 |
Number of instructions compiled | 3 | 1 | 4 | 1 |
Optimisation level | 2 | 4 | 1 | 3 |
Debug aids | 3 | 1 | 2 | 4 |
Loader facilities | 2 | 1 | 3 | 3 |
Library organisation | 2 | 1 | 4 | 2 |
Overlays | 4 | 2 | 1 | 3 |
Overall Order (equal weight) | 4 | 1 | 2 | 3 |