Contact us Heritage collections Image license terms
HOME ACL Associates Technology Literature Applications Society Software revisited
Further reading □ Contents1. Introduction2. Basic symbols and comments3. Identifiers, accumulators and cells4. Types and values5. Addresses and storage allocation6. Simple cell designation7. Assignment statements8. Integer accumulator assignments9. Real accumulator assignments10. Long accumulator assignments11. Cell assignments12. Block structure13. Procedures and labels14. Conditional and control statements15. Functions16. Cell declarations17. Synonym declarations18. Storage allocation19. Subcompilation and global storage20. Define statements, conditional compilation and include statements21. Compiler directives22. FORTRAN/PLASYD mixed programming23. ALGOL/PLASYD mixed programming24. Useful library routines25. Use of TASK macro to compile PLASYD programs26. SMO cell designation27. Compiler output28. PLAN instructions not provided for in PLASYD □ Appendices □ 1: Errors and comments2: 1900 character set3: Syntax definitions in alphabetical order4: Use of program XMED5: 1900 order code6: Code genereated for typical PLASYD statements7: A sample PLASYD program8: Less commonly used directivesReferences
ACD C&A INF CCD CISD Archives Contact us Heritage archives Image license terms

Search

   
ACLLiteratureICL 1906A manualsPLASYD
ACLLiteratureICL 1906A manualsPLASYD
ACL ACD C&A INF CCD CISD Archives
Further reading

Contents1. Introduction2. Basic symbols and comments3. Identifiers, accumulators and cells4. Types and values5. Addresses and storage allocation6. Simple cell designation7. Assignment statements8. Integer accumulator assignments9. Real accumulator assignments10. Long accumulator assignments11. Cell assignments12. Block structure13. Procedures and labels14. Conditional and control statements15. Functions16. Cell declarations17. Synonym declarations18. Storage allocation19. Subcompilation and global storage20. Define statements, conditional compilation and include statements21. Compiler directives22. FORTRAN/PLASYD mixed programming23. ALGOL/PLASYD mixed programming24. Useful library routines25. Use of TASK macro to compile PLASYD programs26. SMO cell designation27. Compiler output28. PLAN instructions not provided for in PLASYD
Appendices
1: Errors and comments2: 1900 character set3: Syntax definitions in alphabetical order4: Use of program XMED5: 1900 order code6: Code genereated for typical PLASYD statements7: A sample PLASYD program8: Less commonly used directivesReferences

23. ALGOL/PLASYD MIXED PROGRAMMING

23.1 Introduction

It is indicated in Chapter 22 that PLASYD segments may be used in FORTRAN programs, and vice-versa. Similarly, it is possible to use PLASYD segments in an Algol program: it is not, however, generally possible to use Algol segments in a PLASYD program.

For example, if the following filestore files exist:

MAINA an Algol main program, which calls the subroutine SUBRP
SUBRP  a PLASYD subroutine

then to compile and consolidate this program, the following TASK system calls are required:

TASK PLASYD, *CR SUBRP, NOCONS, -
TASK ALGOL,  *CR MAINA, LINK

23.2 General Points

The PLASYD segments must be declared in the Algol program: this declaration consists of the appropriate equivalent Algol procedure heading, followed by the basic symbol:

 external;

Thus, a real procedure (that is, a function producing a real result) with two arguments called by value, one integer and the other logical (or Boolean in Algol 60 notation) would require the declaration:

 real procedure fred (A,B); 
 value A,B; 
 integer A; 
 Boolean B; 
 external;

The PLASYD segments may use all Algol parameter types other than Algol procedures, and all the parameters other than expressions (which must be called by value) may be called either by name or by value.

The user should beware of mixing address and branch modes: either the PLASYD should be in the same address and branch modes as the Algol, or, preferably, the programmer should ensure that his coding is branch and address mode compatible (this corresponds to omitting the PLASYD statement SEGMENT MODE, or to using the form SEGMENT MODE (MIXAM, MIXBM) ): in general, to accomplish this latter aim, the instructions BUX and BDX should not be used, and the instruction BCIIX should only be used when the count field (which will not be present in 22AM programs) is not significant. Such PLASYD constructions as

X2 := X2 + CHAR 1; 

satisfy this.

If the PLASYD segment is to be a function, then the result should be left in a standard place, namely the accumulator X6 if it is of type integer or Boolean, or the floating point accumulator if it is of type real.

Note that in Algol, integer and Boolean (logical) variables always occupy one word each, and real variables always occupy two words. There are no double precision or complex types.

23.3 Link Accumulator, Picking up Scalar Parameters

The accumulator used for the link address is always X1, and the user should ensure that this is saved on entry and restored before exit.

The call instruction (in the Algol segment) is followed by n instructions (where n is the number of parameters), the ith of which enables the PLASYD segment to access the ith parameter by performing an OBEY on that instruction.

There are two pitfalls to beware of, otherwise incorrect parameter values may be obtained:

  1. if a parameter has been declared as being called by name, the contents of all accumulators, except X1, may be destroyed when the OBEY instruction for that parameter is executed. Hence, if the contents of any of the other accumulators are significant, they should be stored away before picking up the parameter.
  2. if any of the parameters have been declared as being called by value, then the value of the corresponding actual parameter should be obtained and stored before any parameter called by name is accessed.

The PLASYD program sequence required to access a parameter depends on the type of the parameter, and is detailed below for each parameter type.

integer

Integer variables are held in one word in 1900 Algol.

The OBEY instruction will give, in X3, the address of the word containing the parameter: thus the following will load the value of the third parameter of a procedure to X4:

BEGIN
LOWER INTEGER LINK;
LOWEND;
LINK := X1;
OBEY (X1+2);     [(X1+2) GIVES 3RD PARAMETER]
X4 := (X3);

If the parameter is called by name, then its value may be returned by the PLASYD before exit, thus:

X1 := LINK;    [RESTORE LINK]
OBEY (X1+2); 
X6 := VALUE;   [LOAD AND RETURN VALUE]
(X3) := X6;

Boolean

Boolean variables are held in one word: the value true is indicated by bit 23 of the word being a 1 (ie the word has the contents #00000001) and false by bit 23 of the word being 0 (ie the word has the contents #00000000).

Boolean parameters are picked up and returned in the same way as integer parameters.

Real

Real values are held in floating point form and occupy two words. The picking up of real parameters is similar to the picking up of integers, except that after the OBEY instruction, X3 will contain the address of the first of the two words containing the parameter. The LFP order may then be used to load the value to the floating point accumulator:

BEGIN
   LOWER INTEGER LINK; REAL REALNO;
   LOWEND;
   LINK := X1;
   OBEY (X1+1);    [OBTAIN 2ND PARAMETER]
   A1 := (X3);     [THIS GIVES LFP     0(3)]

Similarly, to return a real value to a parameter called by name:

X1 := LINK; 
OBEY (X1+1); 
A1 := REALNO; 
(X3) := A1;

23.4 Array Parameters

The elements of an array are stored in consecutive units of core store; each unit is one word for integer and Boolean elements, two words for real elements. The order of the elements is such that the leftmost subscript varies the most rapidly, and successive subscripts vary less rapidly; thus the array:

A[1:2,1:2,4:5];

would be stored in the order:

A[1,1,,4],  A[2,1,4], A[1,2,4], A[2,2,4], A[1,1,5],
A[2,1,5], A[1,2,5], A[2,2,5]

Information about an array is held in an array header, which is stored separately from the array. The format of these array headers is not documented; however, there is a routine, GETAH, available to translate these array headers into the information block defined below, and another routine, GENAH, will generate an array header from such an information block. The routines GETAH and GENAH are included in the SRA4 and GROATS libraries.

The information block produced by GETAH and required by GENAH has the following structure:

word 0   number of dimensions (n)
word 1   number of 1900 words per array element
word 2   base address: i.e. the address of the zero element
word 3   address of the first word of the array
word 4   address of the first word after the end of the array
word 5   first partial product 
word 6   second partial product
.....
word n+3 (n-l)th partial product

Thus for an n-dimensional array, this block is of length n+4 words If the array is one dimensional, only words 0-4 are present, and of these, probably word 3 (the address of the first word in the array) is the most useful.

This information block, and the method of obtaining it, applies identically for real, integer and Boolean arrays.

To use GETAH, it is first necessary to pick up the parameter corresponding to the array: this will give in X3 the address of the first word of the array header. This address has to be stored, and then used as a parameter to GETAH, as demonstrated in the following example (this assumes the array is two dimensional, and hence the information block will require 6 words):

BEGIN
   EXTERNAL GETAH (X1); 
   LOWER
      INTEGER ADDRESS, LINK, AH(6); 
   LOWEND; 
   LINK := X1;
   OBEY (X1);       [IF ARRAY IS FIRST PARAMETER] 
   ADDRESS := X3;   [STORE ADDRESS OF ARRAY HEADER] 
   GETAH;
   X3 := ADDRESS;   [NOTE TWO INSTRUCTIONS TO LOAD ADDRESSES] 
   X3 := @AH;

This will produce the required information block in the area AH.

Similarly, if the user wishes to return an array header set up for a PLASYD data area, he should proceed as follows: firstly, set up the information block (as defined above) in the area AH (the length of AH should be appropriate for the number of dimensions the array is to have). Secondly, in the Algol segment, there should be declared an array of the same type and number of dimensions: it should, however, be small in size, as the array will be lost, for example:

 real array AR[1:1, 1:1];

Then, if this array is passed to the PLASYD segment as, say, the first parameter, the array header for the PLASYD area may be returned in place of the Algol array header by use of the routine GENAH, thus:

OBEY (X1);     [X1 CONTAINS LINK ADDRESS]
ADDRESS := X3;
GENAH;
X3 := ADDRESS;
X3 := @AH;

Henceforward, all references to the array in the Algol segments will actually refer to the PLASYD data area.

23.5 Miscellaneous Parameter Types

Strings

The OBEY instruction for a string parameter will place, in X3, the address of the first word of a two word string header. This string header contains, in the first word, the number of characters in the string, and in the second word, the character address of the first character in the string. The string header may well be in a different area of core to the characters in the string.

In the following example, the string is the third parameter to the procedure:

BEGIN
   LOWER  INTEGER LINK,   STRINGCOUNT, CHARADDRESS; 
   LOWEND; 
   LINK := X1;
   ...........
   X1 := LINK;
   OBEY (X1+2);                       [OBTAIN 3RD PARAMETER]
   X6 := (X3);   STRINGCOUNT := X6;   [OBTAIN COUNT]
   X1 := (X3+1); CHARADDRESS := X1;   [OBTAIN ADDRESS]
   ............
   

Labels

The subroutine GOTOLAB may be used to jump to a label in the Algol segment from within a PLASYD segment. It is called as follows:

          EXTERNAL GOTOLAB(X1);
          ..........
          GOTOLAB; 
          X3 := @M; 
          X3 := @N;

where M is the word containing the link address of the PLASYD segment, and N is a word containing the position of the label in the PLASYD procedure's declaration, i.e. the value n if the label is the nth parameter.

The routine GOTOLAB is included in both the Algol and the GROATS libraries. It uses (destroying the previous contents of) accumulators 1, 2 and 3.

In the following example, the procedure fred has the declaration

 procedure fred (I, J, LABEL); 
 integer I, J; 
 label  LABEL; 
 external;

The section of this segment associated with the label parameter would be of the form:

BEGIN
   LOWER INTEGER LINK, I, J, LABELNO = 3; [THE LABEL IS THE THIRD PARAMETER]
   LOWEND;
   EXTERNAL GOTOLAB(X1);
   LINK := X1;
   ...........
   GOTOLAB;                               [JUMP TO LABEL ] 
   X3 := @LINK; 
   X3 := @LABELNO;
   ...........
   X1 := LINK;                            [NORMAL EXIT] 
END;

Switches

The subroutine GOTOSW may be used to jump from a PLASYD segment to a switch in the Algol program. It is called as follows:

   EXTERNAL GOTOSW(X1);
   ..........
   GOTOSW; 
   X3 := @M; 
   X3 := @N; 
   X3 := @P;

where M is the word containing the link address of the PLASYD segment, N is a word containing the position of the switch in the PLASYD procedure's declaration (i.e. the value n if the switch is the nth parameter) and P is a word containing the switch subscript.

The routine GOTOSW is included in both the Algol and the GROATS libraries. It uses (and destroys the contents of) accumulators 1, 2, 3 and 6.

In the following example, the procedure chas is assumed to have the declaration:

 procedure chas (A,SW1); 
 real A; 
 switch  SW1; 
 external;

The section of the PLASYD segment associated with the label parameter would be of the form:

BEGIN
   LOWER INTEGER LINK, POSITION = 2, SUBSCRIPT;   [THE SWITCH is THE SECOND PARAMETER]
   LOWEND;
   EXTERNAL GOTOSW(X1);
   LINK := X1;
   .........
   SUBSCRIPT := X6;       [THE VALUE OF THE SWITCH SUBSCRIPT HAS BEEN CALCULATED IN X6]
   .............
   GOTOSW;
   X3 := @ LINK;
   X3 := @ POSITION;
   X3 := @SUBSCRIPT;
   .............
   X1 := LINK;    [NORMAL RETURN] 
END;

Procedures

It is possible to pass procedures of type external (i.e. not written in Algol) to a PLASYD procedure as parameters. Such a procedure is called from a PLASYD segment, by use of the subroutine PROC. The calling sequence for PROC is:

EXTERNAL PROC(X1);
........
PROC;
X3 := @M; 
X3 := @N; 
X3 := @ARG1;
.........
X3 := @ARGN;
...........

where M is the address of the word containing the link address of the PLASYD segment, N is a word containing the position of the procedure in the PLASYD segment's declaration (ie the value n if the switch is the nth parameter) and ARG1, ARG2,......, ARGN are the arguments to the procedure to be called.

The routine PROC is included in both the Algol and the GROATS libraries. It uses (and destroys the contents of) accumulators 1, 2, 3 and 6.

In the following example, the procedure george is assumed to have the declaration:

 procedure george(A,B,P); 
 real A,B; 
 procedure  P; 
 external;

(The procedure P has one argument.)

The section of the PLASYD segment concerned with the procedure P would be of the form:

BEGIN
    LOWER  INTEGER LINK,   POSITION  =3,  ARG; [THE PROCEDURE P is THE THIRD PARAMETER]
    LOWEND;
    EXTERNAL PROC(X1);
    LINK := X1;
    ...................       [THE ARGUMENT FOR P IS EVALUATED AND STORED IN ARG]
    PROC;
    X3 := @LINK;
    X3 := @POSITION;
    X3 := @ARG;
    ...............
END;

Following the call to PROC, the procedure P will return to the point in this (PLASYD) procedure immediately following the parameters for PROC.

23.6 Accessing Algol Variables

The simple variables declared in the outer block of a master segment of an Algol program are stored in the lower common area ALGOL60 in the order in which they are declared, and may be accessed directly by a PLASYD segment. Arrays, and all variables at other levels of block nesting are stored elsewhere (usually on the stack) and are not available to the PLASYD segment except when used as parameters to procedure calls. The area ALGOL60 is initialised by the master segment at the start of an Algol program, and hence the variables in this area may not be given preset values by the PLASYD segments.

An Algol program uses a stack, which is the top common area (so that it can be extended if necessary). If a PLASYD segment requires an extensible area, then declaring it to be TOPGLOBAL and consolidating the segment into an Algol program will not work, since the consolidator, being offered two top common areas, will treat the second of them (normally the PLASYD TOPGLOBAL area) as an ordinary upper common variable area.

If the program is sparse, there is little difficulty: the PLASYD segment may be written with the extensible area missing, and when it is required, increase the active core size by 1K words (beware -the top bit of the accumulator will be set for GIVE/3 and GIVE/4 extracodes in a sparse program) and start addressing at some unused address, such as 1M = 1048576 (the Algol stack starts at address 512K = 524288): provided the PLASYD was written using a variable to hold the base address of this area, then no problems need arise.

In the case of a dense program, again one method of proceeding is to write the PLASYD using a variable for the base address of the extensible area, which otherwise does not exist. Then when the PLASYD requires this area, it should increase the core size by 1K words and set the previous core size into the variable holding the base address. To ensure that the Algol stack will not be extended across the PLASYD area, an Algol program description statement

'SPACE' n 

with a sufficiently large value of n should be used.

⇑ 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