CORAL 66(ID:499/cor003)

Realtime English military language 


for Computer On-line Realtime Applications Language

Real-time system programming language, a derivative of JOVIAL and ALGOL-60.

CORAL 66 was a major overhaul of CORAL, based on revised ALGOL 60, and improved maths

"1966 by I. F. Currie and M. Griffiths of the Royal Radar Establishment in response to the need for a compiler on a fixed-point computer in a control environment"

Strongly associated with MASCOT, a design technique for real time systems.
Adopted as the British military standard from 1970 until the arrival of Ada.

Places
Related languages
ALGOL 60 Revised => CORAL 66   Based on
CORAL 64 => CORAL 66   Evolution of

References:
  • Woodward P.M. et al, "Official Definition of CORAL 66", HMSO, London, 1970, ISBN 0-11-470221-7. view details Abstract: Coral 66 is a general-purpose programming language based on Algol 60, with some features from Coral 64 and Jovial, and some from Fortran. It was originally designed in 1966 by I. F. Currie and M. Griffiths of the Royal Radar Establishment in response to the need for a compiler on a fixed-point computer in a control environment. In such fields of application, some debasement of high-level language ideals is acceptable if, in return, there is a worthwhile gain in speed of compilation with minimal equipment and in efficiency of object code. The need for a language which takes these requirements into account, even though it may not be fully machine independent, is widely felt in industrial and military work. We have therefore formalized the definition of Coral 66, taking advantage of experience gained in the use of the language. Under the auspices of the Inter-Establishment Committee for Computer Applications, we have had technical advice from staff of the Royal Naval Scientific Service, the Royal Armament Research and Development Establishment, the Royal Radar Establishment, the Defence ADP Training Centre, from serving officers of all three services and from interested sections of industry, to whom all acknowledgments are due.

    The present definition is an inter-service standard for military programming, and has also been widely adopted for civil purposes in the British control and automation industry. Such civil usage is supported by RRE and the National Computing Centre in Manchester, on behalf of the Department of Industry. The NCC has agreed to provide information services and training facilities, and enquiries about Coral 66 for industrial application should be directed to that organization.

  • Jackson, K., and H. R. Simpson. MASCOT - A modular approach to systems construction, operation and testing. AGARD Conference Proc. No. 149 on Real-time Computer-based Systems. NATO May 1974. view details
  • Depledge, N.G. "Coral 66: A Practical High Level Language for Mini Computer Software and Applications Program Development" Honeywell Information Systems Ltd. April 1975 view details Abstract: Almost all computer programs are written in a high level language for strong economic reasons. The only remaining areas of use for assembly languages are systems software implementation and real-time applications programs. The main reason is the lack of compilers for suitable established high level languages. However, CORAL 66 is such a language and has been used with success for several years in the United Kingdom. The special requirements of a high level language for minicomputer software development are discussed. The salient features are listed, as are the computers for which compilers are available or known to be under development. The trade-off between programmer productivity and program performance is discussed. The investment by Honeywell U.K. in CORAL 66 is outlined. The future of CORAL as widely available standardized language is discussed.
  • Rig Associates Inc "Evaluation of CORAL 66, PASCAL, CS-4, TACPOL, CMS-2" Rig Associates Inc Reston Va 18 Nov 76 AD-A037 636/8WC view details
  • The Higher Order Language Working Group (HOLWG) Working Paper on 23 exisitng programming languages view details
  • Halliwell J. D. & T. A. Edwards. "A course in standard CORAL 66" Manchester NCC Publications, 1977. view details
  • Gorman, B.; "The Coral 66 Compiler for Ferranti ARGUS 500 Computer" Royal Signals and Radar Establishment Malvern (England) Jun 78 RSRE-TN-799 view details Abstract: This documentation is a working description of the Coral 66 compiler for the ARGUS 500 produced by RRE under contract from Ferranti Ltd. It serves not only as a guide to the actual operation of the compiler, but also as an exampie of the use of RRE compiler building tools and techniques. These represent the culmination of many man years of research, as also do some of the important Algorithms used within the compiler. The use of the compiler to compile itself makes it to a large extent self checking. Its very modular nature enables testing to be simplified as many modules are non interacting. The central routine, about which the whole compiler is built, uses a transformed syntax which has been exhaustively checked by syntax manipulation programs. These features should enable a high degree of confidence to be placed in the correct operation of the Compiler. Part 1 of this document contains the detailed description of the individual modules forming the Compiler. This is preceded by notes on particular aspects of the techniques and standards used, and by an overall description of the compiler strategy, quoting the syntax rules in which it is embedded. Part 2 consists of printouts of the actual program of the compiler and of the final syntax used. Each of these is accompanied by a list of ail the identifiers used, giving the names of the pages on which they occur, the number of occurrences on each page, and the total number of occurrences.
  • Sammet, Jean E "Roster of programming languages for 1976-77" pp56-85 view details
          in SIGPLAN Notices 13(11) Nov 1978 view details
  • Webb, J. T. "CORAL 66 programming" Manchester, NCC Publications, 1978 view details Extract: Introduction
    This book provides the reader with a comprehensive manual on CORAL 66 and its use. It expands on the Official Definition of CORAL 66 published by the HMSO and provides practical examples of how the language is used. As well as dealing with the basic features and facilities of CORAL 66 it also discusses the problems associated with real time computing and gives detailed advice on how to handle the practical problems encountered in using the language.

    CORAL 66 is a general purpose programming language based mainly on Algol 60 and Jovial but with some features from Fortran. It was originally designed at the Royal Radar Establishment with the intention of making it sufficiently efficient and powerful to be suitable for real time applications using minicomputers. It therefore utilizes a simple storage allocation method, and provides fixed point arithmetic for computers without floating point hardware. Its efficiency makes it ideally suited for many applications, including system programming. This wide suitability resulted in rapidly increasing usage and, eventually, in the need to write this book.

    With the increased usage of CORAL 66 since its adoption as a National Standard in Great Britain, a need arose for a detailed book on the language. This book is based, in part, on experience I gained of both the applications and the Official Definition of CORAL 66 whilst working for the Royal Signals and Radar Establishment, the technical authority for the language. However, the opinions expressed in it are my own and do not necessarily represent official policy. Much of the book is based on a series of articles published in Computer Weekly, whose assistance is gratefully acknowledged.

    Finally, I would like to acknowledge the comments and encouragement of my wife and colleagues in preparing this book.

    J T Webb 19.1.78
    Extract: Language requirements for real time computing
    Language requirements for real time computing

    It may be thought that the achievement of the speed and reliability which are essential to a real time system would be a job for the system designer, and that the language used in such a system is immaterial. However, the practical considerations of the cost of implementing and maintaining a system and the certainty that errors will be made at all stages of the system implementation suggests that all the tools used should be considered very carefully. One of these tools is the language to be used by the programming teams and in this section the requirements for such a language will be considered.
    The basic requirement is, of course, that the use of the language should cut the overall cost of the system. This overall cost should include both the cost of procuring the system and the cost of maintaining and, if necessary, updating it. When considering whether a language meets this basic requirement the following features should be considered:
    -  availability.
    To be viable to the average user or system supplier the language should be readily available on a wide range of computers because the cost of providing a special purpose language could be prohibitive. For a small system the cost of providing the compiler could be excessive and in all systems the training  cost  of   staff  would  be  an  important factor.   Any acceptable language must therefore be readily available. It must also be widely known so that programmers proficient in the language are readily available. These requirements can only be met by a language that is fully developed and stable, is fully supported and has full educational facilities associated with it;

    -  facilities.
    The purpose of high-level languages is to enable the program to be written from the point of view of the problem to be solved, whereas assembly languages reflect the machines which may be used. The ability to write the program from a problem-orientated viewpoint is very important in that it considerably simplifies the writing of the program. The actual level of the language is a factor that has to be carefully considered. If it is too low then not much benefit will be gained from its use, whereas, if it is very high, the program implementation will be made easier for the programmer, but at the expense of inefficient use of the computer itself. This is because a language with very powerful facilites tends to be rather extravagant in the amount of code which it produces. Any language chosen will therefore have to be a compromise between the level required for programming and the degree of computer efficiency which is considered acceptable. This compromise will be determined
    by a consideration of hardware costs and software production costs.

    As hardware costs continue to fall the choice of options may change. However, current costs and experience would indicate that the maximum acceptable loss of efficiency is of the order of 50 per cent. This means that the resulting code should be no more than 50 per cent longer than the equivalent assembly language program, nor should it take more than 50 per cent longer to execute.

    Other factors that need to be considered are the power of the algorithmic features and the data description part of the language.

    The algorithmic features to be looked for would include such items as a subroutine calling mechanism with an adequate range of parameter types, conditional expressions and statements, looping statements, statements for transferring control to another part of a program, a means of communicating between separately compilable segments of program and with other parts of the operating system and a means of manipulating parts of a computer word. The data description part of the language should include all the basic types of variables in both simple and array form. It should also include a means of using storage efficiently by having some form of data packing usable both on simple data and arrays of data. Additional features that would be desirable would be facilities for manipulating data in terms of bits and a method of readily inserting sections of code. In addition to all these points the language should not be significantly less efficient to use on one machine than another.

    The languages currently available are many and varied, but at the present time the only one designed for real time use that is fully supported, widely accepted and equipped with a reasonably rich set of features is CORAL 66. CORAL 66 is descended from ALGOL 60 and an American real time language called Jovial and was adopted as a Ministry of Defence standard in 1970. In 1973 several interested users and manufacturers pressed for its adoption as a nationally accepted standard and as a result of this a support organization was set up at the Royal Signals and Radar Establishment involving the Department of Industry, Ministry of Defence and the National Computing Centre. Several users and manufacturers have also been organized into a committee called the CORAL Group to act in a advisory role to the support organization. The language is therefore widely accepted, fully supported and readily available and its usage is rapidly increasing.
    Extract: Simple introduction to CORAL 66
    Simple introduction to CORAL 66
    A sample program
    The example program listed below reads in numbers from an input file, printing the second to sixth powers of each number as it reads them until it reads a number whose value is less than zero. It introduces various facilities of CORAL 66 and is one complete segment of a program which consists of this segment linked to the items mentioned in the COMMON list at the beginning of the text.
    Some of the words are surrounded by primes and this convention is used on most CORAL 66 compilers to distinguish between basic words and names provided by the programmer. This point will be discussed in greater detail later. The text has been annotated with line numbers down the left-hand side to assist the description. These numbers would not appear in the actual program. The compilers for some computers would also require the provision of names for the complete program and also possibly for portions of the program (if it were what is known as a multi-segment program).

    1      'COMMONS 'PROCEDURE' SELECTTR;
    2               'FLOATING' 'PROCEDURE' READ;
    3               'PROCEDURE' SELECTLP;
    4               'PROCEDURE'   PRINT('VALUE''FLOATING',
    5                                   'VALUE"INTEGERVVALUE"INTEGER'J;
    6               'PROCEDURE'   NEWLINE( 'VALUE " INTEGER');
    7               'PROCEDURE'   WRITETEXT('VALUE' 'INTEGER')   )
    8      'BEGIN'  'FLOATING'  VAL,TEMPI
    9               'INTEGER'I;
    10              SELECTTR;
    11              SELECTLP;
    12       NXT:   VAL:=READ;
    13              TEMP:=VAL;
    14              'IF' VAL<0.0 'THEN' 'GOTO' FIN;
    15              WRITETEXT"     2     3     4     5     6");
    16              NEWLINE(1);
    17              'FOR' I:= 1 'STEP' 1 'UNTIL' 5 'DO'
    18              'BEGIN' TEMP:=TEMP*VAL;
    19                    PRINT(TEMP,5,3)
    20              'END';
    21              'GOTO' NXT;
    22       FIN:  NEWLINE(2);
    23                  WRITETEXT("FINISHED");
    24                     NEWLINE(2);
    25       'END'
    26       'FINISH'

    Line 1 starts with the word 'COMMON' which is known as a com-municator. This is followed by a list of names, and specifications for these names, to be remembered by the compiler. The names, known as identifiers, mentioned refer to items which can be in separately compiled parts of a program. All the separate parts of a complete program are joined together later by another program which is generally called a consolidator or link editor. The first item in this list uses the basic word 'PROCEDURE' to indicate that it refers to a unit of code called a procedure. The meaning of this will be fully described later.
    Lines 2 to 7 introduce other procedures which are used in the program. Procedures may have additional information provided as parameters to tell them what to do. These are shown in brackets. Procedures may also return a value to be used after they have been obeyed eg the procedure READ on line 2.
    Line 8 marks the beginning of a block by means of the word 'BEGIN' and then declares some locations in the computer to be used to hold values required by the calculations. The basic word 'FLOATING' indicates that these are to be used to hold floating point numbers, ie numbers which need not be exact integers.
    Line 9 consists of the declaration of an integer variable, I, which is to be used to hold exact integers and therefore is fundamentally different from a floating number.
    Line 10 calls SELECTTR, one of the procedures mentioned in the 'COMMON' list earlier which selects the tape reader as the channel to be used for the input of data.
    Line 11 is similar but selects the line printer as the channel to be used for the output of results.
    Line 12 starts with the label NXT, the terminator colon marking it as such. This is followed by a statement which is terminated by the semicolon. This statement calls the procedure READ mentioned in the 'COMMON' list which returns the value of the next number on the data lupc and Ihis answer is placed in VAL.
    Line 13 is another statement which copies the value in variable VAL into variable TEMP.
    Line 14 is a more complex statement which conditionally transfers control to the label FIN. This transfer will take place if VAL is less than 0.0. The 'IF' 'THEN' combination controls a 'GOTO' statement but this could have been any unconditional statement, a concept I will discuss in Chapter 6.
    Line 15 calls the 'COMMON' procedure WRITETEXT with a parameter in the form of a string, which is normally used to provide a set of characters for printing. The effect is to send this string to the output channel.
    Line 16 calls the 'COMMON' procedure NEWLINE with the parameter 1 which will cause one newline to be sent to the output channel.
    Line 17 is a 'FOR' statement which in this case controls the compound statement on lines 18 to 20 marked by the 'BEGIN' and 'END', the 'FOR' statement causes this compound statement to be obeyed 5 times by stepping I from 1 to 5 in increments of 1, obeying the compound statement each time.
    Line 18 starts with the 'BEGIN' which marks the beginning of the controlled compound statement. This is followed by a statement which multiplies the contents of TEMP by the contents of VAL and places the result in TEMP, overwriting the previous value.
    Line 19 calls the 'COMMON' procedure PRINT with three parameters which results in the contents of TEMP being sent to the output channel allowing for 5 places before the decimal point and 3 after. It should be noted that in this case the statement is not terminated by a semicolon because the 'END' in line 20 acts as the terminator as well as the end of the compound statement. This complete compound statement is terminated by the semicolon on line 20 and it should also be noted that the distinction between a block (started on line 8) and a compound statement (lines 18 to 20) is in the presence or absence of declarations (lines 8 and 9 in this example).
    Line 21 consists of a 'GOTO' statement which causes control to be transferred to the label NXT so that the program repeats the process of reading the next number from the input channel.
    Line 22 starts with the label FIN mentioned in line 14, followed by another call of the 'COMMON' procedure NEWLINE, this time with the parameter 2 to cause 2 newlines to be output. Line 23 causes the text FINISHED to be sent to the output device.
    Line 24 causes two more newlines to be output and this statement is terminated by a semicolon despite the 'END' on line 25. This means that there is a null statement between the semicolon and the 'END' which will have no effect.
    Line 25 consists solely of the word 'END' which marks the end of the block started on line 8.
    Line 26 consists solely of the word 'FINISH' which marks the end of the compilation unit. Although in a correct program this can be deduced by matching the 'BEGIN's and 'END's, if a mistake is present it provides a useful indication of the intended finishing point.
    One of the most noticable things about the program is the way it is arranged to repeat parts over and over again. It is solely by this means lhat a few instructions can generate a large number of calculations. The importance of adequate control and looping instructions is obvious and the following example shows a different way of writing the program which eliminates 'GOTO' statements. This is a useful achievement in that it generally makes a program easier to design, write, and maintain.

    'COMMON'( 'PROCEDURE' SELECTTR;
    'FLOATING' 'PROCEDURE' READ;
    'PROCEDURE' SELECTLP;
    'PROCEDURE' PRINT('VALUE' 'FLOATING',
                                'VALUE' 'INTEGER','VALUE' 'INTEGER');
    'PROCEDURE' NEWLINEC VALUE "INTEGER');
    'PROCEDURE' WRITETEXT('VALUE"INTEGER') )
    'BEGIN' 'FLOATING' VAL.TEMP;
              'INTEGER' I;
              SELECTTR; SELECTLP;
              'COMMENT' THIS FOR LOOP NOW CONTROLS THE LOOPING;
              'FOR' VAL:=READ 'WHILE' VAL>0.0 'DO'
              'BEGIN' TEMP:=VAL;
              NEWLINE(1);
              WRITETEXT('       2345                 6"),'
              'FOR'   I:= 1   'STEP'  1   'UNTIL'  5  'DO'
                   'BEGIN'  TEMP:=TEMP*VAL;
                        PRINT(TEMP,5,3)
                   'END'
              'END';
              NEWLINE(2);
              WRITETEXT('FINISHED"); NEWLINE(2)
    'END'
    'FINISH'


    We now have another ' FOR' loop on the line below one of the available forms of comment (delimited by the word 'COMMENT' and the semicolon). This 'FOR' loop is a different form from the stepping type used in the earlier program in that it obeys the assignment statement VAL: = READ; checks that VAL>0.0 is true, obeys the controlled statement, in this case a compound statement, and repeats the process. The complete sequence will be repeated until a number less than or equal to 0 is found. The remainder of the program is basically the same as before and the compound statement is marked by the additional 'BEGIN' and 'END'.

          in SIGPLAN Notices 13(11) Nov 1978 view details
  • Library of Congress Subject Headings C29 view details
          in SIGPLAN Notices 13(11) Nov 1978 view details
    Resources