BS 5904-1980 Specification for computer programming language RTL 2《计算机程序设计语言RTL 2规范》.pdf

《BS 5904-1980 Specification for computer programming language RTL 2《计算机程序设计语言RTL 2规范》.pdf》由会员分享，可在线阅读，更多相关《BS 5904-1980 Specification for computer programming language RTL 2《计算机程序设计语言RTL 2规范》.pdf（52页珍藏版）》请在麦多课文档分享上搜索。

1、BRITISH STANDARD BS 5904:1980 Incorporating Amendment Nos. 1 and 2 Specification for Computer programming language RTL/2 UDC 681.3.06RTL/2BS5904:1980 This British Standard, having been prepared under the directionof the Data ProcessingStandards Committee, was published under the authorityofthe Execu

2、tive Board and comes into effect on 30September1980 BSI 03-2000 The following BSI references relate to the work on this standard: Committee reference DPS/13 Draft for comment 78/64581 DC ISBN 0 580 11441 4 Cooperating organizations The Data Processing Standards Committee, under whose direction this

3、British Standard was prepared, consists of representatives from the following Government departments and scientific and industrial organizations: British Computer Society Ltd.* British Equipment Trade Association* British Paper and Board Industry Federation (PIF) British Printing Industries Federati

4、on Central Computer Agency (Civil Service Department)* Committee of London Clearing Bankers on behalf of the Committee of Scottish Clearing Bankers, Cooperative Bank, Central Trustee Savings Bank and Yorkshire Bank Department of Industry (Computers Systems and Electronics) Department of Industry (Na

5、tional Physical Laboratory)* Electricity Supply Industry in England and Wales* Government Communications Headquarters HM Customs and Excise Institute of Cost and Management Accountants Institute of Purchasing and Supply Institution of Electrical Engineers Institution of Mechanical Engineers Inter-un

6、iversity Committee on Computing London Transport Executive Ministry of Defence* National Computer Users Forum National Computing Centre Ltd.* National Research Development Corporation Post Office* Society of British Aerospace Companies Limited The organizations with an asterisk in the above list, to

7、gether with the following, were directly represented on the committee entrusted with the preparation of this British Standard: Association for Literary and Linguistic Computing Association of Computer Units in Colleges of Higher Education (ACUCHE) British Gas Corporation Computing Services Associati

8、on Control and Automation Manufacturers Association (BEAMA) Edinburgh Regional Computing Centre Engineering Equipment Users Association Hatfield Polytechnic University of London Amendments issued since publication Amd. No. Date of issue Comments 3722 July 1981 8233 October 1994 Indicated by a sideli

9、ne in the marginBS5904:1980 BSI 03-2000 i Contents Page Cooperating organizations Inside front cover Foreword ii 1 Scope 1 2 Reference 1 3 Definitions 1 4 Syntax 1 4.1 Syntactic metalanguage 1 4.2 Example 1 4.3 Syntax requirements 1 5 Examples 5 6 Compliance 5 6.1 Implementations 5 6.2 Programs 6 7

10、Requirements 6 7.1 Basic elements 6 7.2 Declarations 12 7.3 Expressions 22 7.4 Statements 33 7.5 Modules 40 7.6 Integrity 41 Appendix A Information on input/output 43 Appendix B Information on error recovery 44 Appendix C Recommendation on compiler limits 44 Figure 1 Numerical mode conversion in con

11、ditional expressions 25 Figure 2 Numerical mode conversion for operands 27 Table 1 Alphabetical lists of syntax requirements 2 Table 1A Item syntax 2 Table 1B Module syntax 3 Table 2 RTL/2 character set 7 Table 3 Keywords 9 Table 4 Monadic operators, operands and results 28 Table 5 Dyadic operators,

12、 operands, results and precedence 29 Table 6 Form of result of use of shift operators 30 Publications referred to Inside back coverBS5904:1980 ii BSI 03-2000 Foreword This standard has been prepared under the direction of the Data Processing Standards Committee and extracts in this standard from “RT

13、L/2 Language Specification”, Version2, ICI, 1974 are reproduced by permission of Imperial Chemical Industries Limited. In drafting this standard the continued stability of RTL/2 has been a prime objective. However, apart from changes to clarify or correct the specification, a few minor alterations h

14、ave seemed advisable. These affect the scope of record component names, strings, LET definitions, equality of label values and the character set. These alterations have been carefully designed to correct features of the original specification that with hindsight have proved to be inappropriate and y

15、et do not alter the semantics of valid programs. RTL/2 provides a method for writing both application and system programs for use in real-time computing and is especially suited for on-line data acquisition, communication and control systems. The overall objectives of the language are: a) to reduce

16、the direct cost of the development and maintenance of software; b) to encourage the creation of more reliable systems; c) to increase the mobility of programming staff; d) to provide continuity of method and flexibility in choice of equipment by ensuring the portability of application programs. RTL/

17、2 is designed to be as machine-independent as practicable even at the expense of certain (probably obsolescent) machine architectures. RTL/2 recognizes, however, that operating systems need a degree of flexibility that is incompatible with the security needs of application programs. Accordingly, RTL

18、/2 comprises two languages, the full language being the system language, and a secure subset (see7.6) being the application language. It is virtually impossible to define precisely a high-level language so that programs will be executed equally efficiently by all types of computer. It has therefore

19、been necessary to leave certain areas of RTL/2 deliberately unspecified so that implementations can take the best advantage of characteristics of particular computers. The most, important of these areas are: a) accuracy and range of real values; b) number of bits in an integer word; c) behaviour on

20、arithmetic overflow. Such areas are indicated in this standard by the use of phrases such as “implementation-dependent”. On the other hand, it should be noted that the representation of integer values has been explicity specified to be in twos complement form; thus implementations of RTL/2 on comput

21、ers that do not use this representation will be less efficient. Program structure. A computer that is not specifically designed to execute RTL/2 code directly would need to be enhanced with various control routines to create an RTL/2 machine. In a simple single-state machine, the rest of the softwar

22、e, if derived from RTL/2, could be of items of software of similar status and this group of items would be known as a “program complex”. More usually, however, and of necessity in a two-state machine, the remaining software has a hierarchical structure. The top level, usually known as the “superviso

23、r”, is itself a program complex and the individual groups of lower levels can themselves be considered to be program complexes, but with an environment different from that of the supervisor complex. An RTL/2 complex consists of a collection of items known as bricks, of which there are the following

24、types: a) procedure brick; b) data brick; c) stack brick.BS5904:1980 BSI 03-2000 iii A procedure brick consists of the declaration of a single literal procedure. A procedure is a read-only piece of code describing an executable process, and may have parameters and local variables, but the latter are

25、 restricted to be scalars. The entry mechanism and implementation of local variables is reentrant. The coding of a procedure may directly access variables in a data brick, but not the local variables or parameters of another procedure. A procedure may not include internal procedures. A data brick is

26、 a named static collection of scalars, arrays and records. A stack brick consists of the declaration of a single literal stack. A stack is an area used for the storage of links, dynamic (i.e. local) variables and other housekeeping items. Several bricks may be grouped together to form a module that

27、is the unit of compilation. A program complex is the result of linking together one or more such modules. The compiler needs to be informed of the environment of a module for satisfactory compilation to take place. This environment, in general, consists of two parts; first there is the environment o

28、f the complex as a whole and secondly there are interfaces with other modules in the complex. The environment of the complex as a whole is, in the case of the supervisor, simply the enhanced machine, whereas in the case of a complex running under the supervisor in a two-state machine, it also consis

29、ts of the environment provided by that supervisor. This environment comprises a set of procedures accessed as supervisor calls (SVC procedures) plus a set of data bricks private to each task and nominally housekept by the supervisor (SVC data). A module needs to include descriptions of SVC procedure

30、s and data bricks that it accesses. To reference a brick within another module in the complex, a description of the brick needs to be included in the referring module, and the brick referred to in the other module needs to have been specified as an external entry in that module. The various cross-re

31、ferences implied by these environment descriptions are satisfied by the linker program (see7.5). Multitasking. A program complex may represent a simple program with a definite start and finish. It could however consist of the code and data for several processes running concurrently, and in order to

32、describe such a complex the term “task” is introduced. A task, broadly speaking, is an identifiable execution of a logically coherent set of instructions by a (pseudo-) processor. A conventional computer with a single processor can be considered to be obeying at all times one unique task. It is, how

33、ever, usually more convenient to consider the execution of each logically distinct process as a task and to convert the one actual processor into several psuedo-processors by a scheduling algorithm within a supervisor. As a language, RTL/2 imposes few constraints on the design of multitasking system

34、s and the actual facilities of such systems are outside the scope of this standard. It is, however, possible to describe in outline the intended relationships between the various bricks in a multitasking system. The creation, control and elimination of tasks will, in general, be performed by a super

35、visor, and the supervisor call (see 7.5) will provide the channel for the communication of task and control requests.BS5904:1980 iv BSI 03-2000 Whenever a new task is created, a stack will be nominated as workspace and a procedure will be nominated as the coding to be obeyed. Later operations on the

36、 task may be made by reference to its stack. Each stack can, of course, be used only by one task at a time, whereas procedures and data bricks may be used by several concurrent tasks. The procedure nominated as coding can call other procedures and access variables in data bricks as required. Communi

37、cation between tasks can be via supervisor calls and any message scheme provided by the supervisor, or simply via data bricks with the suitable use of semaphores. An SVC data brick is private to each task and may be used in a reentrant manner. It will be housekept on task changes and this might well

38、 be implemented by mapping it on to part of the stack. Editorial note. It is normal convention in British Standards to use italic type for algebraic quantities. Since the status of such quantities contained in this standard may or may not directly represent true variable quantities, this convention

39、has not been adopted in this standard. A British Standard does not purport to include all the necessary provisions of a contract. Users of British Standards are responsible for their correct application. Compliance with a British Standard does not of itself confer immunity from legal obligations. Su

40、mmary of pages This document comprises a front cover, an inside front cover, pagesitoiv, pages1to44, an inside back cover and a back cover. This standard has been updated (see copyright date) and may have had amendments incorporated. This will be indicated in the amendment table on the inside front

41、cover.BS5904:1980 BSI 03-2000 1 1 Scope This British Standard specifies the semantics and syntax of the computer programming language RTL/2 by specifying requirements for a compiler and for a conforming program. NOTEThe specification requirements have been drafted so that all features of RTL/2 are e

42、ither explicity defined, or explicity stated to have been left intentionally undefined. Appendix A contains information regarding input/output. Appendix B contains information on error recovery. Appendix C makes a recommendation on compiler limits. 2 Reference The title of the publication referred t

43、o in this standard is given on the inside back cover. 3 Definitions For the purposes of this British Standard the definitions given in BS3527apply. 4 Syntax 4.1 Syntactic metalanguage 1) . The notation used in this standard to specify the syntax of the language is as follows. a) The terminal symbols

44、 of the language denote themselves. The names of classes are in lower case letters whereas the language alphabet is represented by the upper case letters. Items are separated from each other by spaces where necessary. b) The metasymbol 4 denotes “is”, and the metasymbol|denotes “or”. c) The brackets

45、 and are used to denote that the items enclosed within are optional. d) A sequence of three dots . denotes that the immediately preceding item may be repeated many times. 4.2 Example. The following example denotes that a “name” is a sequence of letters and digits of which the first is a letter. A “d

46、igit” is one of 0, 1 . 9 and a “letter” is one of A, B . Z. The individual digits and letters are terminal symbols and cannot be decomposed further. In the text, the names of classes are enclosed in quotes when formal correctness is emphasized. In less formal passages the quotes are omitted. 4.3 Syn

47、tax requirements. The syntax requirements, with references to relevant text in clause7, are specified inTable 1. NOTEThe syntax requirements listed inTable 1 should be interpreted in a synthetic rather than analytic way. It is intended primarily for the user of this standard to determine the form in

48、 which a program is to be written and reference to this standard by a compiler, to determine whether a form is valid, is a secondary consideration. In some cases involving the class “identifier”, the syntax is ambiguous (i.e. it allows two parses to some forms), and semantic information (the mode of

49、 the identifier) is required to determine which parse should be used. These cases are as follows. a) In the production of “arrayelement”, both “variable” and “array” can be resolved to “identifier”. b) In the production of “recordcomponent”, both “variable” and “record” can be resolved to “identifier”. c) In the production of “constant”, both “identifier” and “variable” can be resolved to “identifier”. d) In the production of “primary”, both “functioncall” and “variable” can be resolved to “identifier ( expn , expn . )”. The syntax of RTL/2 is pre