Contact us Heritage collections Image license terms
HOME ACL Associates Technology Literature Applications Society Software revisited
Further reading □ OverviewNo.1No.2No.3No.4No.5No.6No.7No.8No.9No.11No.12No.13No.14No.15
ACD C&A INF CCD CISD Archives Contact us Heritage archives Image license terms

Search

   
ACLLiteratureProgress ReportsPDP15 Notes
ACLLiteratureProgress ReportsPDP15 Notes
ACL ACD C&A INF CCD CISD Archives
Further reading

Overview
No.1
No.2
No.3
No.4
No.5
No.6
No.7
No.8
No.9
No.11
No.12
No.13
No.14
No.15

PDP15 User Note No 6: Bug concerning FORTRAN EXTERNAL statement

W D Shaw

25 February 1975

PROBLEM

The FORTRAN statement:

      EXTERNAL A,B,C,D 

declares procedures A,B,C, and D as external global symbols to be passed as formal arguments in a subsequent subroutine call such as:

      CALL FANCY(32,C) 

The F4V44 FORTRAN compiler generates a word for each external global symbol called a transfer vector. Transfer vectors should be modified by the loader to contain the run-time addresses of the external procedures to which they refer. Thus, external globals may be addressed using a single indirect reference. If A,B,C and D are all FORTRAN subroutines, the transfer vectors are properly updated to point to the entry points of the routines. It appears, however, that transfer vectors corresponding to MACRO procedures are not set at all, but left zero! No diagnostic is issued by F4V44 or LOADER.

The effect of this bug is that references to an external MACRO procedure are, in effect, references to location 0. Usually, the reference is a JMS 0, causing an IOPS error.

The bug may be avoided by writing a trivial FORTRAN procedure which calls the MACRO procedure and returns. The FORTRAN procedure must be declared external.

⇑ Top of page
© Chilton Computing and UKRI Science and Technology Facilities Council webmaster@chilton-computing.org.uk
Our thanks to UKRI Science and Technology Facilities Council for hosting this site