forked from s390guy/vm370
-
Notifications
You must be signed in to change notification settings - Fork 0
/
PL360MAN.LISTING.D1
3883 lines (3336 loc) · 178 KB
/
PL360MAN.LISTING.D1
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1 CONTENTS
+ CONTENTS
+ CONTENTS
SECTION 1. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . 1-1
SECTION 2. DEFINITION OF THE PL360 ENVIRONMENT
2.1 Terminology, Notation, and Basic Definitions . . . 2-1
2.1.1 The Processor . . . . . . . . . . . . . . . 2-1
2.1.2 Relationships . . . . . . . . . . . . . . . 2-2
2.1.3 The Program . . . . . . . . . . . . . . . . 2-2
2.1.4 Syntax . . . . . . . . . . . . . . . . . . 2-2
2.2 Identifiers and Basic Symbols . . . . . . . . . . 2-3
2.2.1 Identifiers . . . . . . . . . . . . . . . . 2-4
2.2.2 Basic Symbols . . . . . . . . . . . . . . . 2-4
2.2.3 Standard Identifiers . . . . . . . . . . . 2-5
SECTION 3. VALUES
3.1 Hexadecimal Values . . . . . . . . . . . . . . . . 3-1
3.2 Decimal Values . . . . . . . . . . . . . . . . . . 3-1
3.3 Numeric Values . . . . . . . . . . . . . . . . . . 3-2
3.4 String Values . . . . . . . . . . . . . . . . . . 3-2
SECTION 4. PROGRAM FORMAT
4.1 Block Structure . . . . . . . . . . . . . . . . . 4-1
4.2 Program Segmentation . . . . . . . . . . . . . . . 4-3
4.3 Data Segmentation . . . . . . . . . . . . . . . . 4-3
4.4 Main Program . . . . . . . . . . . . . . . . . . . 4-4
SECTION 5. DECLARATIONS
5.1 Register Synonym Declarations . . . . . . . . . . 5-1
5.2 Segment Base Declarations . . . . . . . . . . . . 5-1
5.3 Cell Declarations . . . . . . . . . . . . . . . . 5-2
5.4 Cell Designators . . . . . . . . . . . . . . . . . 5-3
5.5 Cell Synonym Declarations . . . . . . . . . . . . 5-4
5.6 EQUATE Declarations . . . . . . . . . . . . . . . 5-5
SECTION 6. STATEMENTS
6.1 Register Assignments . . . . . . . . . . . . . . . 6-1
6.2 Register Assignment Expressions . . . . . . . . . 6-2
6.3 Cell Assignments . . . . . . . . . . . . . . . . . 6-3
6.4 GOTO Statements and Labels . . . . . . . . . . . . 6-4
6.5 Conditions and Compound Conditions . . . . . . . . 6-4
6.6 IF Statements . . . . . . . . . . . . . . . . . . 6-6
6.7 WHILE Statements . . . . . . . . . . . . . . . . . 6-6
6.8 FOR Statements . . . . . . . . . . . . . . . . . . 6-7
6.9 CASE Statements . . . . . . . . . . . . . . . . . 6-7
SECTION 7. FUNCTIONS
7.1 Function Declarations . . . . . . . . . . . . . . 7-1
7.2 Function Statements . . . . . . . . . . . . . . . 7-1
SECTION 8. PROCEDURES
8.1 Procedure Declarations . . . . . . . . . . . . . . 8-1
8.2 Procedure Statements . . . . . . . . . . . . . . . 8-2
SECTION 9. THE RUN-TIME LIBRARY
9.1 Standard Procedures . . . . . . . . . . . . . . . . 9-1
9.2 Number Conversion Procedures . . . . . . . . . . . 9-2
9.3 Data Manipulation Procedures . . . . . . . . . . . 9-4
B i
1
SECTION 10. COMPILER CONTROL FACILITIES
10.1 Instructions to the Compiler . . . . . . . . . . . 10-1
10.1.1 Listing Control . . . . . . . . . . . . . 10-1
10.1.2 Listing Options . . . . . . . . . . . . . 10-1
10.1.3 Operating System Control . . . . . . . . . 10-2
10.1.4 Identification . . . . . . . . . . . . . . 10-2
10.1.5 Program Base Register Control . . . . . . 10-2
10.1.6 Object Deck Control . . . . . . . . . . . 10-3
10.1.7 Copy Facility . . . . . . . . . . . . . . 10-3
10.1.8 Conditional Compile Directives . . . . . . 10-3
10.2 Compiler Listing Output . . . . . . . . . . . . . 10-4
10.3 Error Messages of the Compiler . . . . . . . . . . 10-5
10.4 Compiler Object Program Output . . . . . . . . . . 10-6
SECTION 11. LINKAGE CONVENTIONS
11.1 Calling External Routines from PL360 . . . . . . . 11-1
11.2 Requesting Supervisor Services . . . . . . . . . . 11-2
11.3 Calling PL360 Procedures from External Routines . 11-2
SECTION 12. PL360 AS AN ORVYL LANGUAGE PROCESSOR
12.1 Using the PL360 Compiler with ORVYL . . . . . . . 12-1
12.2 Input/Output Subroutines for
Interactive PL360 Programs . . . . . . . . . . . 12-3
APPENDIX A. EXAMPLE PROGRAMS AND LISTINGS
Sample Program Demonstrating Extensions to PL360 . . . A-1
Right Triangle Problem . . . . . . . . . . . . . . . . A-6
Global Procedure TRTEST . . . . . . . . . . . . . . . A-9
ORVYL Program to Set Options . . . . . . . . . . . . . A-11
APPENDIX B. THE OBJECT CODE . . . . . . . . . . . . . . . . . . . B-1
APPENDIX C. COMPILER CONSTRUCTS . . . . . . . . . . . . . . . . . C-1
APPENDIX D. SYNTACTIC INDEX . . . . . . . . . . . . . . . . . . . D-1
APPENDIX E. SYNTACTIC ENTITIES . . . . . . . . . . . . . . . . . . E-1
TABLES
+ TABLES
+ TABLES
Table 6.1 Allowable Cell and Register Type Combinations . . . . . 6-1
Table 6.2 Allowable Cell and Value Combinations . . . . . . . . . 6-3
Table 6.3 Condition Code States . . . . . . . . . . . . . . . . . 6-5
Table 7.1 Instruction Format . . . . . . . . . . . . . . . . . . . 7-2
Table B.1 Object Code Operators . . . . . . . . . . . . . . . . . B-1
Table C.1 2-Byte Instructions . . . . . . . . . . . . . . . . . . C-2
Table C.2 4-Byte Instructions . . . . . . . . . . . . . . . . . . C-3
B ii
1
REFERENCES
+ REFERENCES
+ REFERENCES
[1] N. Wirth: PL360. "A Programming Language for the 360 Computers,"
JACM 15 (1968) 37.
[2] SCIP/Academic Computing Services Program Libraries, Polya Hall
Stanford University.
[3] J. Eve: "PL360 Language Extensions," Internal Note, Computing
Laboratory. University of Newcastle upon Tyne.
[4] G. M. Amdahl, G. A. Blaauw, F. P. Brooks, Jr.: "Architecture
of the IBM System/360," IBM Journal of Research and Development 8
(1964) 87.
[5] G. A. Blaauw et al. "The structure of System/360," IBM Systems
Journal 3 (1964) 119.
[6] "IBM System/360 Principles of Operation," IBM A22-6821.
[7] "IBM System/360 OS Assembler Language," IBM C28-6514.
[8] MTS Vol. I, University of Michigan Computation Center, Ann Arbor.
[9] "IBM System/360 Linkage Editor and Loader" IBM C28-6538.
[10] "PL360 Programming Manual," University Computing Laboratory,
University of Newcastle upon Tyne, Caremont Tower, Newcastle upon
Tyne, NE1 7RU, England, 1970.
[11] "IBM System/360 DOS System Control and System Service Programs,"
IBM C24-5036
[12] R. Fajman and J. Borgelt, "ORVYL User's Guide," Stanford
University Computation Center, 1971.
[13] "IBM System/360 Disk Operating System Supervisor and Input/Output
Macros," IBM C24-5037.
[14] N. Wirth: "Format of PL360 Programs," ALGOL W - Project Memo,
Stanford University, Sept. 9, 1966.
B iii
1
FOREWORD
+ FOREWORD
+ FOREWORD
The intent of this manual is to provide a reference tool for programmers
using PL360. Although it is not a textbook, it has been organized in
such a way that each section introduces new material dependent on
information covered in preceding sections. In that sense, it can serve
as a self-teaching aid.
Those readers not familiar with Bacus-Naur Form (BNF), may find the
syntactic rules used to describe the language difficult to understand.
However, the textual descriptions and examples associated with a set of
syntactic rules should serve to clarify those rules. Also, the sample
programs of Appendix A further clarify the language structure.
Knowledge of the 360 architecture [4, 5 or 6] is a prerequisite for
understanding the language definition and some familiarity with the 360
Assembly Language [7] and linkage editor [8] is assumed in the
description of the object code produced by the compiler.
In writing this manual, the authors have drawn heavily upon the
(anonymous) PL360 Programming Manual published by the University of
Newcastle upon Tyne, Computing Laboratory [10].
B iv
1
SECTION 1. INTRODUCTION
+ SECTION 1. INTRODUCTION
+ SECTION 1. INTRODUCTION
PL360 is a programming language designed specifically for the IBM
System/360 computers. It provides the facilities for a symbolic machine
language but displays a structure similar to that of ALGOL. A formal
description of an earlier version of the language has been published by
Niklaus Wirth [1] who directed the development of the PL360 language and
its compiler at the Computer Science Department of Stanford University.
Although PL360 was originally designed for writing logically
self-contained programs, subsequent extensions permit communication with
separately compiled programs.
An efficient one pass "in core" compiler, written by Niklaus Wirth,
Joseph W. Wells, Jr. and Edwin Satterthwaite, Jr., which incorporates
these extensions is available through the Stanford Program Library [2].
This compiler translates PL360 source code into object modules in the
format required by several 360 operating systems (OS and MTS for
example). The documentation issued with the compiler includes several
amendments to the original language definition. Further extensions were
carried out at the University of Newcastle by James Eve. These changes
[3,10] were aimed primarily at relaxing the linkage constraints on
separately compiled programs, enabling for example direct communication
with programs using OS/360 type linkages. Michael Malcolm of the
Stanford Computer Science Department made several modifications to the
version of the compiler produced by James Eve. These extensions made it
possible to run the compiler and compiled programs under DOS operating
systems. Assembly language subroutines were also written for both OS
and DOS to facilitate input-output with sequential tape and disk files.
Dick Guertin of the Stanford Center for Information Processing extended
the syntax of PL360, primarily to increase programming convenience. He
has also written assembly language interfaces to allow interactive use
of both the PL360 compiler and PL360 programs under the ORVYL
time-sharing monitor at Stanford. Andrew Koening of Columbia University
also contributed improvements to the compiler.
The language definition and compiler description incorporating all
changes are given in this manual. For a full discussion of the
background underlying the development of PL360 and a description of the
organization and development of the compiler together with some
perceptive comments on the 360 architecture, reference must still be
made to [1], where the aims of the language are summarized:
... it was decided to develop a tool which would:
1. allow full use of the facilities provided by the 360
hardware,
2. provide convenience in writing and correcting programs, and
3. encourage the user to write in a clear and comprehensible
style.
As a consequence of 3, it was felt that programs should not be
able to modify themselves. The language should have the
facilities necessary to express compiler and supervisor
programs, and the programmer should be able to determine every
detailed machine operation.
B 1-1
1
SECTION 2. DEFINITION OF THE PL360 ENVIRONMENT
+ SECTION 2. DEFINITION OF THE PL360 ENVIRONMENT
+ SECTION 2. DEFINITION OF THE PL360 ENVIRONMENT
2.1 Terminology, Notation, and Basic Definitions
+2.1 Terminology, Notation, and Basic Definitions
+2.1 Terminology, Notation, and Basic Definitions
The language is defined in terms of a computer which is comprised of a
number of processing units and a finite set of storage elements. Each
of the storage elements holds a content, also called value. At any
given time, certain significant relationships may exist between storage
elements and values. These relationships may be recognized and altered,
and new values may be created by the processing units. The actions
taken by the processors are determined by a program. The set of
possible programs form the language. A program is composed of, and can
therefore be decomposed into elementary constructions according to the
rules of a syntax, or grammar. To each elementary construction
corresponds an elementary action specified as a semantic rule of the
language. The action denoted by a program is defined as the sequence of
elementary actions corresponding to the elementary constructions which
are obtained when the program is decomposed (parsed) by reading from
left to right.
2.1.1 The Processor
+2.1.1 The Processor
+2.1.1 The Processor
At any time, the state of the processor is described by a sequence of
bits called the program status word (PSW). The status word contains,
among other information, a pointer to the next instruction to be
executed, and a quantity which is called the condition code.
Storage elements are classified into registers and core memory cells,
simply called cells. Registers are divided into three types according
to their size and the operations which can be performed on their values.
The types of registers are:
a. integer or logical (a sequence of 32 bits)
b. real (a sequence of 32 bits)
c. long real (a sequence of 64 bits)
Cells are classified into five types according to their size and the
type of value which they may contain. A cell may be structured or
simple. The types of simple values and simple cells are:
a. byte or character (a sequence of 8 bits = 1 byte)
b. short integer (a sequence of 16 bits = 2 bytes, interpreted
as an integer in two's complement binary notation)
c. integer or logical (a sequence of 32 bits = 4 bytes,
interpreted as an integer in two's complement binary
notation)
d. real (a sequence of 32 bits = 4 bytes, interpreted as a
base-16 floating-point number)
e. long real (a sequence of 64 bits = 8 bytes, interpreted as
a base-16 floating-point number)
The types integer and logical are treated as equivalent in the language,
and consequently only one of them, namely integer, will be mentioned
throughout this manual. Likewise, byte and character are equivalent and
only byte is mentioned.
B 2-1
1
2.1.2 Relationships
+2.1.2 Relationships
+2.1.2 Relationships
The most fundamental relationship is that which exists between a cell
and its value. It is known as containment; the cell is said to contain
the value.
Another relationship exists between the cells which are the components
of a structured cell, called an array, and the structured cell itself.
It is known as subordination. Structured cells are regarded as
containing the ordered set of the values of the component cells.
A set of relationships between values is defined by monadic and dyadic
functions or operations, which the processor is able to evaluate or
perform. The relationships are defined by mappings between values (or
pairs of values) known as the operands, and values known as the results
of the evaluation. These mappings are not precisely defined in this
manual; instead, see [6].
2.1.3 The Program
+2.1.3 The Program
+2.1.3 The Program
A program contains declarations and statements. Declarations serve to
list the cells, registers, procedures, and other quantities which are
involved in the algorithm described by the program, and to associate
names, called identifiers, with them. Statements specify the operations
to be performed on these quantities, to which they refer through the use
of identifiers.
A program is a sequence of tokens, which are basic symbols, strings or
comments. Every token is itself a sequence of characters. The
following conventions are used:
a. Basic symbols constitute the basic vocabulary of the
language (cf. 2.2.2). They are either single characters,
or uppercase letter sequences.
b. Strings are sequences of characters enclosed in quote marks
i.e. "string" (cf. 3.4).
c. Comments are sequences of characters (not containing a
semicolon) preceded by the basic symbol COMMENT and
followed by a semicolon (;). Comments may also be written
as a sequence of characters between vertical bars (!).
Thus, ! this is a comment ! It is understood that comments
have no effect on the execution of a program.
In order that a sequence of tokens be an executable program, it must be
constructed according to the rules of the syntax.
2.1.4 Syntax
+2.1.4 Syntax
+2.1.4 Syntax
A sequence of tokens constitutes an instance of a syntactic entity (or
construct), if that entity can be derived from the sequence by one or
more applications of syntatic substitution rules. In each such
application, the sequence equal to the right side of the rule is
replaced by the symbol which is its left side.
B 2-2
1
Syntactic entities (cf. Appendix D, E) are denoted by english words
enclosed in brackets < and >. These words describe approximately the
nature of the syntatic entity, and where these words are used elsewhere
in the text, they refer to that syntactic entity. For reasons of
notational convenience and brevity, the uppercase letters A, K, and T
are also used in the denotation of syntactic entities. They stand as
abbreviations for any of the following words (or pairs):
A K T
+ A K T
+ A K T
long real long real long real
real real real
integer integer integer
short integer short integer
byte
Syntactic rules are of the form <E> ::= & where <E> is a syntactic
entity (called the left side) and & is a finite sequence of tokens and
syntactic entities (called the right side of the rule). The notation
<E> ::= &1 ! &2 ! ... ! &n
is used as an abbreviation for the n syntactic rules
<E> ::= &1, <E> ::= &2, ..., <E> ::= &n
If in the denotations of constituents of the rule the uppercase letters
A, K, or T occur more than once, they must be replaced consistently, or
possibly according to further rules given in the accompanying text. As
an example, the syntactic rule
<K-register> ::= <K-register identifier>
is an abbreviation for the set of rules
<long real register> ::= <long real register identifier>
<integer register> ::= <integer register identifier>
<real register> ::= <real register identifier>
2.2 Identifiers and Basic Symbols
+2.2 Identifiers and Basic Symbols
+2.2 Identifiers and Basic Symbols
The implementation imposes the restriction that only the first 10
characters of identifiers are recognized as significant.
Throughout this section, user defined identifiers are shown in lowercase
letters to distinguish them from standard identifiers and basic symbols.
In actual practice, all identifiers are constructed from uppercase
letters.
B 2-3
1
2.2.1 Identifiers
+2.2.1 Identifiers
+2.2.1 Identifiers
<letter> ::= A!B!C!D!E!F!G!H!I!J!K!L!M!N!O!P!Q!R!S!T!U!V!W!X!Y!Z
<digit> ::= 0 ! 1 ! 2 ! 3 ! 4 ! 5 ! 6 ! 7 ! 8 ! 9
<identifier> ::= <letter> ! <identifier><letter> ! <identifier><digit>
<K-register> ::= <identifier>
<T-cell identifier> ::= <identifier>
<procedure identifier> ::= <identifier>
<function identifier> ::= <identifier>
<integer value identifier> ::= <identifier>
An identifier is a K-register, T-cell, procedure, function, or integer
value identifier, if it has respectively been associated with a
K-register, T-cell, procedure, function, or integer value (called a
quantity) in one of the blocks surrounding its occurrence (cf. 4.1).
This association is achieved by an appropriate declaration. The
identifier is said to designate the associated quantity. If the same
identifier is associated with more than one quantity, then the
considered occurrence designates the quantity to which it was associated
in the innermost block embracing the considered occurrence. In any one
block, an identifier must be associated with exactly one quantity. In
the parse of a program, that association determines which of the rules
given above applies.
Any processing computer and operating system can be considered to
provide an environment in which the program is embedded, and in which
some identifiers are permanently declared. Some identifiers are assumed
to be known in every environment; they are called standard identifiers,
and are listed in Section 2.2.3.
2.2.2 Basic Symbols
+2.2.2 Basic Symbols
+2.2.2 Basic Symbols
Basic symbols which consist of uppercase letter sequences shown below
are denoted by the same letter sequences without further distinction.
Such letter sequences are called reserved words and cannot be used as
identifiers. Embedded blanks are not allowed in reserved words,
identifiers, and numbers. Adjacent reserved words, identifiers, and
numbers must be separated by at least one blank or other
non-alphanumeric. Otherwise, blanks may be used freely. The basic
symbols are:
+ - * / ( ) = < > ¬
, ; . : @ # _ " ' !
DO IF OF OR
ABS AND END FOR NEG SYN XOR
BASE BYTE CASE DATA ELSE GOTO LONG NULL
REAL SHLA SHLL SHRA SHRL STEP THEN
ARRAY BEGIN CLOSE DUMMY SHORT UNTIL WHILE
COMMON EQUATE GLOBAL
COMMENT INTEGER LOGICAL SEGMENT
EXTERNAL FUNCTION REGISTER
CHARACTER PROCEDURE
B 2-4
1
2.2.3 Standard Identifiers
+2.2.3 Standard Identifiers
+2.2.3 Standard Identifiers
The following identifiers are predeclared in the language but may be
redeclared due to block structure. Their predefined meanings are
specified in Section 5, Section 7.1, or Section 9.1.
MEM
B1 B2 B3 B4 B5 B6 B7 B8 B9 B10 B11 B12 B13 B14 B15
R0 R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11 R12 R13 R14 R15
F0 F2 F4 F6
F01 F23 F45 F67
BALR CLC CLI CVB CVD ED EDMK EX IC
LA LH LM LTR MVC MVI MVN MVZ NC NI OC OI PACK
RESET SET SLDA SLDL SPM SRDA SRDL STC STH STM SVC
TEST TM TR TRT TS UNPK XC XI
CARRY FALSE MIXED OFF ON OVERFLOW STRING TRUE
CANCEL GET KLOSE OPEN PAGE PRINT PUNCH PUT READ WRITE
B 2-5
1
SECTION 3. VALUES
+ SECTION 3. VALUES
+ SECTION 3. VALUES
3.1 Hexadecimal Values
+3.1 Hexadecimal Values
+3.1 Hexadecimal Values
Values may be expressed in hexadecimal notation.
<hexadecimal digit> ::= <digit> ! A ! B ! C ! D ! E ! F
<hexadecimal value> ::= # <hexadecimal digit>
! <hexadecimal value> <hexadecimal digit>
A hexadecimal value denotes a sequence of bits. Each hexadecimal digit
stands for a sequence of four bits defined as follows:
0 = 0000 4 = 0100 8 = 1000 C = 1100
1 = 0001 5 = 0101 9 = 1001 D = 1101
2 = 0010 6 = 0110 A = 1010 E = 1110
3 = 0011 7 = 0111 B = 1011 F = 1111
Note: If hexadecimal values are used in conjunction with arithmetic or
logical operators in a program, they must be considered as a sequence of
bits which constitute the computer's representation of the number on
which the operator is applied. Hexadecimal values followed by the
letter R or L may be used to denote numbers in unnormalized
floating-point representation [4,5,6].
3.2 Decimal Values
+3.2 Decimal Values
+3.2 Decimal Values
<unsigned integer number> ::= <digit>
! <unsigned integer number> <digit>
<unsigned short integer number> ::= <unsigned integer number> S
<fractional number> ::= <unsigned integer number> .
! <fractional number> <digit>
<scale factor> ::= <integer number>
<floating-point number> ::= <fractional number>
! <fractional number> ' <scale factor>
! <unsigned integer number> ' <scale factor>
<unsigned real number> ::= <floating-point number>
! <unsigned integer number> R
<unsigned long real number> ::= <floating-point number> L
! <unsigned integer number> L
<A-number> ::= <unsigned A-number>
! _ <unsigned A-number>
Integer, real, and long real numbers are represented in decimal
notation. The latter two can be followed by a scale factor denoting an
integral power of 10. Short integers are distinguished from integers by
the letter S following the number. In order to denote a negative
number, an unsigned number is preceded by the underscore symbol "_".
(Note: the underscore is used so as not to confuse negative values with
the subtract operator "-", which is never part of a number.)
Note: A-number is an abbreviation for long real number, real number,
short integer number and integer number as defined in section 2.1.4 as a
notational convenience.
B 3-1
1
3.3 Numeric Values
+3.3 Numeric Values
+3.3 Numeric Values
<byte value> ::= <integer number> X
<short integer value> ::= <short integer number>
! <hexadecimal value> S
<integer value> ::= <integer number>
! <hexadecimal value>
! <integer value identifier>
<real value> ::= <real number>
! <hexadecimal value> R
<long real value> ::= <long real number>
! <hexadecimal value> L
Examples:
byte values: 2X _5X
short integer values: 10S #FF00S
integer values: 0 #106C _1 size
real values: 1.0 _3.14 2.7'8 #46000001R
long real values: 0L 3.14159265359L #4E00000000000001L
3.4 String Values
+3.4 String Values
+3.4 String Values
There are also string values, but these are not generally used in
conjunction with arithmetic or logical operators.
<string> ::= " <character sequence> "
! <hexadecimal value> X
<character sequence> ::= <character>
! <character sequence> <character>
<character> ::= <any EBCDIC character except "> ! ""
When a string is a character sequence enclosed in quote marks, the
string is limited to a total of 255 characters. If a quote mark (") is
to be a character of the sequence, it is represented by a pair of
consecutive quote marks.
When a string is a hexadecimal value ending in X, up to 16 hexadecimal
digits may be specified. Each pair of hexadecimal digits represents one
character. If the number of hexadecimal digits specified is odd, a
hexadecimal 0 is prefixed to the specified value to make the total even.
Examples: "ABC" denotes the sequence ABC
"A""Z" denotes the sequence A"Z
#C1C2C3X denotes the sequence ABC
B 3-2
1
SECTION 4. PROGRAM FORMAT
+ SECTION 4. PROGRAM FORMAT
+ SECTION 4. PROGRAM FORMAT
Compiler input records consist of 80 characters. The first 72
characters of each record are processed as part of a PL360 program;
characters 73 through 80 are listed but not otherwise processed.
Character 72 of one record is considered to be immediately followed by
character 1 of the next record. Character position 1 may contain any
character except '$' or any other character (e.g., /) that would signal
a compiler control statement or job control statement.
4.1 Block Structure
+4.1 Block Structure
+4.1 Block Structure
<program> ::= <block> . !
GLOBAL <simple procedure heading>;<statement> . !
GLOBAL <simple procedure heading> BASE <integer register>;<statement>
<block> ::= <block body> END
<block body> ::= <block head> ! <block body><statement>; !
<block body><label definition>
<block head> ::= BEGIN ! <block head><declaration>;
<declaration> ::= <T-cell declaration> !
<function declaration> ! <procedure declaration> !
<T-cell synonym> ! <K-register synonym> !
<integer value synonym> !
<segment base declaration> ! <segment close declaration>
<label definition> ::= <identifier> :
<statement> ::= <simple statement> ! <IF statement> !
<WHILE statement> ! <FOR statement>
<simple statement> ::= <K-register assignment> !
<T-cell assignment> ! <function designator> !
<procedure statement> ! <CASE statement> ! <GOTO statement> !
<block> ! NULL
A block has the form
BEGIN D; D; ...; D; S; S; ...; S; END
where the D's stand for declarations and the S's for statements
optionally preceded by label definitions. END may be labeled. The two
main purposes of a block are:
1. To enclose a sequence of statements into a structural unit
which as a whole is classified as a simple statement. The
constituent statements are executed in sequence from left
to right.
2. To introduce new quantities and associate identifiers with
them. These identifiers may be used to refer to these
quantities in any of the declarations and statements within
the block, but are not known outside the block.
The symbol NULL denotes a simple statement which implies no action at
all.
B 4-1
1Example of a block:
BEGIN INTEGER BUCKET;
IF FLAG THEN
BEGIN BUCKET := R0; R0 := R1; R1 := R2;
R2 := BUCKET;
END ELSE
BEGIN BUCKET := R2; R2 := R1; R1 := R0;
R0 := BUCKET;
END
RESET(FLAG);
END
The addressing mechanism of the 360 computers is such that instructions
can indicate addresses only relative to a base address contained in a
register. The programmer must insure that
1. every address in the program specifies a "base" register
2. the specified register is loaded with the appropriate base
address whenever an instruction whose address refers to it
is executed
3. the difference d between the desired absolute address and
the available base address satisfies 0 <= d < 4096
This scheme not only increases the amount of 'clerical' work in
programming, but also constitutes a rich source of pitfalls. PL360 is
designed to ease the tedious task of base address assignment, and to
provide checking facilities against errors.
The solution adopted here is that of program segmentation. The program
is subdivided into individual parts, called segments. Every quantity
defined within the program is known by the number of the segment in
which it occurs and by its displacement relative to the origin of that
segment. The problem then consists of subdividing the program and
choosing base registers in such a way that
a. the compiler knows which register is used as base for each
compiled address
b. the compiler can assure that each base register contains
the desired base address during execution
c. the number of times base addresses are reloaded into
registers is reasonably small
It was decided [1] that the programmer should express explicitly which
parts of the program are to constitute segments. The program may then
be organized in a way that minimizes the number of cross-references
between segments.
It should be noted that a programmer's knowledge about segment sizes and
occurrences of cross-reference is quite different for programs than for
data. In the latter case the programmer is aware of the precise amount
of storage needed for the declared quantities, and knows precisely where
in the program references to a specific data segment occur. In the
former case, knowledge about the eventual size of a compiled program
section is only vague, and the programmer is sometimes unaware of the
occurrence of branch instructions implicit in certain constructs of the
language. It was therefore decided [1] to treat programs and data
differently; this decision also conformed with the desirability of
keeping program and data apart as separate entities.
B 4-2
1
4.2 Program Segmentation
+4.2 Program Segmentation
+4.2 Program Segmentation
A program segment corresponds to a CSECT in assembly language. The
outermost block of a program is always compiled as a segment. Since by
its very nature control lies in exactly one segment at any instant, one
register is designated to hold the base address of the program segment
currently executing. Register R15 is usually used for this purpose
(however, cf. 8.1, 10.1.5). Branching to another segment is
accomplished with a procedure statement which causes the program segment
base register of the destination segment to be loaded with its base
address before branching into that segment (cf. 8.2).
The natural unit for a program segment is the procedure (cf. 8.1). The
normal way to enter a procedure is via a procedure statement (cf. 8.2),
and the normal way to leave it is at its end, or by a call to another
procedure which does not return. An explicit GOTO statement cannot be
used for branching from one segment to another, but may be used to
branch out of a local procedure within a segment. The fact that no
implicitly generated instructions can ever lead control outside of a
segment mimimizes the number of cross references in a natural way. Only
relatively large procedures should constitute program segments, and a
facility is provided to designate such procedures explicitly. A
procedure to be compiled as a program segment must contain the symbol
SEGMENT or GLOBAL in its heading.
4.3 Data Segmentation
+4.3 Data Segmentation
+4.3 Data Segmentation
For data, the programmer is aware of the precise amount of allocated
memory and of the instances where references are made to these
quantities. A base declaration was therefore introduced which implies
that all quantities declared thereafter within the same block and
preceding another base declaration, refer to the specified register as
their base. These quantities form a data segment. At the place of the
base declaration, an instruction is compiled which loads the register
with the appropriate segment address (except for dummy base declarations
and BASE R0); however, its previous contents are neither saved nor
restored upon exit from the block.
Data segments declared in parallel (i.e., not nested) blocks, can safely
refer to the same base register. Data segments declared within the same
block usually refer to different base registers. Data segments declared
within nested blocks should also refer to different base registers. If
they do not, it is the programmer's responsibility to ensure that the
register is appropriately loaded when a segment is addressed.
There is no limit to the size of data segments. All cell identifiers
must, however, refer to cells whose addresses differ from the segment
base address by less than 4096. If they do not, the compiler provides
an appropriate diagnostic.
B 4-3
1
4.4 Main Program
+4.4 Main Program
+4.4 Main Program
A PL360 program which is a block is considered to be embedded in a
global procedure such as the following: (cf. 8.1)
GLOBAL PROCEDURE SEGN001 (R14) BASE R15;
BEGIN STM(R14,R12,B13(12)); R14 := R13;
BEGIN GLOBAL DATA SEGN000 BASE R13;
ARRAY 18 INTEGER B13;
B13(4) := R14; B14(8) := R13;
B14(16) := B14(16) XOR B14(16);
BEGIN COMMENT Main program block;
END;
R13 := B13(4); LM(R14,R12,B13(12));
END;
END.
The 18 integer area is reserved to conform to procedure calling
conventions (cf. 9.1). If the PL360 program is a global procedure, there
is no implicit base declaration for the data area (cf. 4.3).
When a program is defined as a block, the compiler supplies a transfer
address for the linkage editor or loader [9], and provides the necessary
entry and exit code for linking with a standard operating system (cf.
10.1.3).
When a program is defined as a global procedure, no transfer address is
supplied, and all linkage code must be written by the programmer.
Both types of program are included in the sample programs of Appendix A.
B 4-4
1 SECTION 5. DECLARATIONS
+ SECTION 5. DECLARATIONS
+ SECTION 5. DECLARATIONS
5.1 Register Synonym Declarations
+5.1 Register Synonym Declarations
+5.1 Register Synonym Declarations
The System/360 processor has 16 registers which contain integer numbers
and are said to be of type integer (or logical). They are designated by
the standard register identifiers: R0 through R15 (cf. 2.2.3).
The processor also has four registers which contain real numbers or long
real numbers. If those registers are used in conjunction with real
numbers, they are said to be of type real, and are designated by the
standard register identifiers:
F0, F2, F4, F6
If they are used in conjunction with long real numbers, they are said to
be of type long real, and are designated by the standard register
identifiers:
F01, F23, F45, F67
The above register identifiers are assumed to be predeclared, and other
identifiers can be associated with these registers. Reference to
specific registers in the text apply to register synonyms also.
<K-register synonym> ::=
<simple K-type> REGISTER <identifier> SYN <K-register> !
<K-register synonym> , <identifier> SYN <K-register>
5.2 Seqment Base Declarations
+5.2 Seqment Base Declarations
+5.2 Seqment Base Declarations
<segment base declaration> ::=
<segment base heading> BASE <integer register>
<segment base heading> ::= SEGMENT ! GLOBAL DATA <identifier> !
EXTERNAL DATA <identifier> ! COMMON DATA <identifier> !
COMMON ! DUMMY
<segment close declaration> ::= CLOSE BASE
A segment base declaration causes the compiler to use the specified
register as the base address for the cells subsequently declared in the
block in which the base declaration occurs. The segment is terminated
either by the END of the block or by the subsequent appearance of a
segment close declaration. Upon entrance to this block, the appropriate
base address is assigned to the specified base register except for the
dummy base declaration and base declarations that specify BASE R0 (cf.
4.3).
If the symbol DATA is preceded by any of the symbols GLOBAL, EXTERNAL or
COMMON, the corresponding identifier is associated with the data segment
to enable linking of segments in different PL360 programs [8,9,12].
Appearance of the symbol sequence COMMON BASE causes a blank
identification to be associated with the segment (cf. 10.4).
B 5-1
1
Note: Dummy base declarations permit the description of data areas
which are created during the execution of the PL360 program. Any
integer register may be specified in a dummy base declaration. When R0
(or a synonym to R0) is specified in any base declaration, the
subsequent identifiers are understood to have displacements and no base
register (or index register).
5.3 Cell Declarations
+5.3 Cell Declarations
+5.3 Cell Declarations
<simple byte type> ::= BYTE ! CHARACTER
<simple short integer type> ::= SHORT INTEGER
<simple integer type> ::= INTEGER ! LOGICAL
<simple real type> ::= REAL
<simple long real type> ::= LONG REAL
<T-type> ::= <simple T-type> ! ARRAY <integer value><simple T-type>
<T-cell declaration> ::= <T-type><item> ! <T-cell declaration>,<item>
<item> ::= <identifier> ! <identifier> = <fill value>
<fill value> ::= <T-value> ! <string> !
@<procedure identifier> ! @@<procedure identifier> !
@<T-cell designator> ! @@<T-cell identifier> !
<repetition list><fill value>)
<repetition list> ::= ( ! <integer value>( !
<repetition list><fill value>,
A cell declaration introduces identifiers and associates them with cells
of a specified type belonging to the currently active base declaration
segment (cf. 4.3). The scope of validity of these cell identifiers is
the block in whose heading the declaration occurs (cf. 4.1). Moreover,
a declaration may specify the assignment of an initial value to the
introduced cell. This assignment is understood to have occurred before
execution of the program.
A cell may be initialized to numeric values, strings, relative or
absolute addresses. The number of bytes appropriate for the type of the
declared cell is taken for each (numeric) T-value. Strings are never
expanded or truncated; each character of the string occupies one byte,
initialization starting with the leftmost byte. A short integer or
integer type cell can be initialized to the relative address (i.e., base
register and displacement) corresponding to a T-cell identifier or to
the relative (entry point) address corresponding to a procedure
identifier by means of the @ operator. The @ operator also permits the
initialization of an integer type cell with the relative address (i.e.,
index register, base register and displacement) of a T-cell designator.
The @@ operator enables integer type cells to be initialized with
absolute addresses corresponding to T-cell identifiers or to the entry
point of procedure identifiers.
If a simple type is preceded by the symbol ARRAY and an integer value,
say n , then the declared cell is an array (ordered set) of n cells of
the specified simple type. An initial value list with m <= n entries
specifies the initial values of the first m elements of the array. A
list may be specified as a list of sublists. Repetition of a sequence
of elements may be specified by making the sequence into a list and
preceding it by an integer value, say k , specifying the number of times
the list is to be used. If no integer value precedes a list, it is used
once. Absolute addresses may not occur in lists where k > 1 . Integer
values n and k must be positive.
B 5-2
1
Note: Boundary alignment is performed for a cell declaration (according
to the simple type) and not for each initializing value. Because
strings are never expanded or truncated, care is needed in initializing
with combinations of strings and other values.
Examples:
BYTE flag
SHORT INTEGER i,j,k = 10S,m = (5), baddr = @basepoint
LONG REAL x,y,z = 27'3L
ARRAY 3 INTEGER size = (36,23,37),parmlist = (@@a,@@b,@@erproc)
ARRAY 132 BYTE blank = 132(" "),buff = 33(" ",2("*")," ")
ARRAY fbsize LOGICAL area = fbsize(0)
5.4 Cell Designators
+5.4 Cell Designators
+5.4 Cell Designators
<T-cell designator> ::= <T-cell identifier>
! <T-cell identifier> ( <index> / <integer value expression> )
! <T-cell identifier> ( <index> )
<index> ::= <integer value expression>
! <integer register expression>
! <integer register expression> + <integer value expression>
! <integer register expression> - <integer value expression>
<integer register expression> ::= <integer register>
! <integer register> + <integer register>
<integer value expression> ::= <integer value>
! <integer value expression> + <integer value>
! <integer value expression> - <integer value>
Note: The second form of <T-cell designator> may be specified at any
time, but only has meaning for the first <T-cell designator> of
<T-cell assignment> ::= <T-cell designator> := <T-cell value>
and
<condition> ::= <T-cell designator> <relation> <T-cell value>