bookhtml/ 0040755 0066576 0066562 00000000000 06403024332 0013067 5 ustar 00rjp cs_lec 0000255 0004314 bookhtml/appenda.html 0100644 0066576 0066562 00000006557 06403022614 0015400 0 ustar 00rjp cs_lec 0000255 0004314
The order of evaluation of expressions was said to be from left to right in chapter 2. This is obviously not the whole story and SIMULA actually follows normal rules of operator precedence and bracketing.
When an expression is evaluated any parenthesised sub-expressions within it are evaluated fully first. This rule is applied recursively, so that nested sub-expressions are always evaluated before their enclosing expression. Where an expression contains more than one parenthesised sub-expression, these are evaluated left to right.
Thus the following Boolean expressions are true.
2 * 2 + 3 + 4 * 5 = 27 2 *(2 + 3)+ 4 * 5 = 30 (2 *(2 + 3)+ 4)* 5 = 70
Within these categories, triples are evaluated from left to right.
Thus the following are true.
4 + 2 // 2 = (2 // 2) + 4 7 * 8 + 3 * 11 ** 4 = ((11 ** 4) * 3) + (7 * 8)Note how parantheses can make expressions easier to read, even if they do not change the meaning.
The following rules govern where conversion is performed:
Thye type of the final value will depend on the type of the terms after application of these rules. Type conversion is always performed before the operation is performed.
Short integer to integer conversion is always exact.
Integer to short integer conversion resulting from assignment of an integer value to a short integer location or passing an integer value as a short integer parameter is exact where it is possible. Where the integer's value lies outside the range of short integer values for that system, the attempted conversion will cause a runtime error. All value ranges are system dependent.
Real to long real conversion should involve no loss of precision, since long reals are required to allow greater or equal precision. Some systems restrict the range of long real values to obtain greater precision, compared to reals. In these systems it is possible to cause a runtime error by attempting to convert a real to a long real.
Long real to real conversion may result in loss of precision. If the value range of long real exceeds that of real for the system, a runtime error will result if the long real is outside the real range.
Integer to real or long real conversion is exact within some system defined range, which must include zero. Outside that range it may be non-exact. In general no range errors should be possible.
Real or long real to integer or short integer may cause a runtime error if the is defined as equivalent to adding 0.5 to the value and taking the integer part of the result. Thus 3.5 becomes 4, while -3.5 becomes -3.
The system procedures AddEpsilon and SubEpsilon (see chapter 20) are provided to help with advanced numerical programming. They determine the sensitivity of real or long real values to addition and subtraction respectively.
<sign?><spaces?><integer_part><exponent?> or < sign?><spaces?><integer_part?><decimal_mark><fractional_part><exponent?> or < sign?><exponent>A plus or minus sign is optional. A plus has no effect; a minus denotes a negative number.
The integer part is optional when a decimal mark and fractional part are given. It consists of a sequence of digits. When no fractional part is given an integer part followed by an exponent is regarded as a real or long real constant.
There must be a decimal mark if there is a fractional part. The system will normally expect a full stop (period), but this can be reset using the system procedure DecimalMark (see chapter 20). This also allows the current mark to be checked.
The fractional part is another, non-empty, string of digits.
The exponent is optional where at least a fractional part is given, but may be used on its own. It consists of the lowten symbol followed by an integer value. It specifies a power of ten by which the value of the rest of the number is to be multiplied or is itself, combined with a sign part if present, the value of the number.
The lowten character is normally ampersand (&) for real numbers and double ampersand (&&) for long reals. Note that this allows the precision of the number to be specified for constants. The ampersand is replaced by any character passed to the system procedure LowTen (see chapter 20). This procedure also returns the current character.
Valid real constants include:
2.67 0.54 .54 - 12.68&-6 &&12
PutReal has two parameters. The first is the real or long real value to be represented, the other controls the precise format.
Real values are printed with a single lowten character, long reals with a double.
The second, integer parameter of PutReal has the following effects:
Thus the following calls produce the output given:
PutReal(34.56,0) -> &+01 PutReal(34.56,1) -> 3&+01 PutReal(34.56,2) -> 3.5&+01Systems may vary in the number of digits output for the exponent. You should consult the documentation for the system you are using.
OutReal takes a third parameter, which is an integer used to specify the total width allocated for the number to be output, as explained in chapter 8. endix A.
Short integer to ibookhtml/appendc.html 0100644 0066576 0066562 00000001621 06403024063 0015365 0 ustar 00rjp cs_lec 0000255 0004314
Appendix C: Alternative number bases.
SIMULA allows integers to be specified to number bases other than 10. This
applies to integer parts, fractional parts and exponent values, as well as all
uses of integers (see appendix B).
The format of such an integer, which may be preceded where appropriate by a sign (not in fractional parts), is:
<radix>R<appropriate_digits>Radix is the number specifying the base to be used and must be one of 2, 4, 8 or 16.
The digits which may be used will depend on the choice of base, as follows:
2 -> 0,1 4 -> 0,1,2,3 8 -> 0,1,2,3,4,5,6,7 16 -> 0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,FExamples of this form for simple integers are:
2R1010 16RFFFE 8R76501bookhtml/appendd.html 0100644 0066576 0066562 00000002110 06403024514 0015361 0 ustar 00rjp cs_lec 0000255 0004314
In practice it is wise to use these with caution.
Some simple examples are:
IntVal := if A=B then IntVal + 1 else IntVal = 2Here IntVal is incrreased by 1 if A=B, otherwise it is increased by 2.
(if A=B then Obj1 else Obj2).Val := 6Here the value 6 is assigned to attribute Val of Obj1 if A=B, otherwise it is assigned to attribute Val of Obj2. Note that the reference expression must be enclosed in brackets to avoid ambiguity and that Obj1 and Obj2 must be qualified by the same class.
These examples should give a sufficient idea of the use of this feature. bookhtml/chap01.html 0100644 0066576 0066562 00000036504 06334361743 0015053 0 ustar 00rjp cs_lec 0000255 0004314
This book describes how to write and understand programs written in the language SIMULA. The definition used is the 1985 SIMULA Standard, which extends and clarifies the language previously known as SIMULA 67. The 67 stood for 1967, the year in which this earlier version was first defined.
These should not be confused with the older language known as SIMULA 1, which is an ancestor of SIMULA 67 and thus of today's SIMULA.
A few old references to SIMULA (notably a 1966 article in CACM) will mean SIMULA 1. More often SIMULA 67 is intended. Many implementations of SIMULA will not yet have all the features given in the 1984 standard, although they will probably have more than those defined in 1967. Wherever sensible this book tries to warn its readers of features which may not be universally available. In addition, it is usually a good idea to check the documentation for the particular SIMULA system to be used, in case it has any peculiarities of its own. SIMULA is highly standardised, but differences may still be found.
You may already be familiar with other programming languages such as Fortran, Basic or Pascal. Even so you will find this introduction essential, since SIMULA views the world rather differently in some ways. In particular SIMULA expects you to organise or structure your program carefully. It also allows you to describe actions as if they were happening simultaneously or in parallel.
If the next paragraph seems confusing, read it now and see how much you can understand, then come back after each chapter until it makes complete sense. Do the same for any other parts of this book which are not clear at first reading. Remember that in learning a new computer language you are trying to take in many concepts which only make sense together, so that often several re-readings of what will later seem obvious points are necessary.
A SIMULA program is made up of sequences of instructions known as
blocks, which act independently to varying degrees, but which are combined
to produce the desired overall effect. The simplest programs contain
only one block, known as the program block. All other blocks follow the
same basic rules, so let us have a look at the single block program, example 1.1.
and had a complete program block. This tells us the first rule about all blocks.
A block always begins with the word begin and ends with the word
end.
beginand end are called "keywords", since they are reserved for special purposes
and may not be used for anything else.
This is made up of instructions to the SIMULA system, which are of two types;
DECLARATIONS and STATEMENTS. There are also pieces of the text which
are ignored by the SIMULA system and which simply help any human who reads the
program to follow what is happening. These are called comments.
Declarations in a block show how much of the computer's memory is going to be
needed by that block. They also show into how many sections it is to be divided ,
how big each is to be and to what sort of use each will be put. Each of these
sections is given a name, by which the program will refer to it.
The program block in example 1.1 has only one declaration. It starts with the
"type" keyword integer, followed by a name or "identifier", Int1.
The type (integer in this example) says what the section of memory will be used for. In example 1.1
it will be used to hold a whole number, which is called an integer
in SIMULA. Once a section of memory has been given its type in this way,
it may not be used to hold something of a different type.
Since this location will hold an integer its required size will also be
known to the SIMULA system. All items of the same type require the same amount
of space in memory to hold them.
The identifier Int1 is now the name of the space reserved in this way. We may
sometimes refer to the value held in this space as Int1 also. This is a
useful shorthand, especially when we are not aware what the current contents
are.
If we want to use more locations, we can declare them in the same way,
being careful to give the correct type to each. Thus we might write
Which gives us a location of type real and called Real1, which we
can use in this block. The possible types and their uses are explained
more fully in chapter 3.
If we want to have more than one location which can hold a whole
number, then we can declare a second integer, with a different identifier.
We might do this by writing
or, alternatively, by writing
which many people find neater. This style is called a declaration list,
with a series of identifiers of locations with the same type separated by commas.
It has no effect on what the program does, but it
contains some information on what the program is or does. In example 1.1 it tells
us which version of the program we are looking at. This is often very useful.
As well as forming lines on their own, comments can also be used in certain
places within instructions or combined on the same line as them. This will be
shown in the next chapter.
When you are writing programs in independent sections, as we will be, you may
not look back at a "working" component for some time. It is also possible
that someone else may need to change what you have written. The design of the
overall system should tell him what the component is supposed to do, but the
details of how it works may not be obvious. To help everyone understand your
programs, you should include comments in them.
We shall be looking at the different sorts of statements which exist
in SIMULA in detail later. For the moment, let us look briefly at those
in the example to get a flavour of the possibilities.
The first one is an "assignment" statement. It tells the system to
place something in one of the locations declared for use by this block.
In this case the value three is to be stored in the integer location
declared as Int1. Since this value is of a type which matches that
declared for the location the statement is legal SIMULA.
The next statement uses something called OutInt, which is a
"procedure" and is available in all SIMULA systems. OutInt will write
out the first number in the parentheses - ordinary brackets - after it. It
writes it as a whole number at the end of the line, or "image",
which is currently being created. The second number is used to tell the
system how much space to use on the line, when writing out the first number.
The final statement uses OutImage. Like OutInt, OutImage is a
procedure and is available in all SIMULA systems. Such standard
procedures are known as "system procedures". They are not keywords, since you
may declare a different meaning for them within a block if you wish.
OutImage causes the line which is currently being created - the current
image - to be written to the printer or terminal and a new line to be
started. You have probably noticed that it does not have any parentheses
or numbers after it. These numbers, known as "parameters", are only
present when the procedure needs information from the program to carry
out its task.
The first step is to write our program, known in full as the "source
program", in some medium which the computer housing the SIMULA
system can manipulate. Older machines may require you to punch the text
on paper tape or cards, but today most machines will handle text files.
These are stored in the computer's memory on some magnetic medium such as
a disk or tape. You can usually create them by typing them into the system
using a text editor. You will need to check the documentation for the
computer that you intend to use, especially the SIMULA user's guide or
programmer's reference manual.
Once you have created this "machine readable" version of the source
program, the part of the SIMULA system known as the "compiler" must be
used to read the source and create a sequence of "machine instructions",
which tell the computer what the SIMULA program wants to do. This is known
as "compiling" the program.
Machine instructions are different on different types of computer. If you want
to move a SIMULA program from one computer to another type of computer, you must
re-process the source, with the compiler of the SIMULA system on the second
machine. This is sometimes referred to as recompiling the program on the
second machine.
Once you have compiled the program, you may have to "link" the file of machine
instructions which has been generated by the compiler. Not all computers require
this step. The file produced by the compiler is known as the object file and the
translation of your source program which it holds is known as the "object program".
Linking - sometimes called linkage editing - merges the object program version
of your program with the standard programs already available in the SIMULA
system - the "runtime system" or "runtime library". These allow reading and
writing, standard maths functions and so forth to be used; OutInt is made available
in this way. Where linking is not necessary, these standard procedures are found
by the command which runs the program.
Details of how to compile and, if necessary, link your program should be
available to you in the user's guide or programmer's reference manual for your
SIMULA system. Where on-line "help" information is available on your computer,
this may provide a useful summary. Where you have access to professional
advisers or more experienced SIMULA users, you may be able to save a lot of
time by asking them for help, but you should still read the documentation
carefully, since not everyone uses all the features of a large programming
language like SIMULA.
The final product of compilation and linking is a translation of your original
SIMULA source into instructions which your computer can obey. You can now
"run" the file containing these and see your program work. Again you
should consult the documentation for your computer for details of how to do
this.
In this chapter we have looked informally at what a program and a
block are. We used a very simple program, made up of only one block to
illustrate this.
We discovered that a block is a series of instructions, preceded by
the keyword begin and followed by the keyword end.
Instructions are either declarations, which reserve and name
locations, in which information of one particular type may be kept, or
statements, which tell the SIMULA system to perform some action.
Lastly we looked at how to compile and run our program on a computer.
This chapter has introduced a lot of ideas. You may feel completely
bewildered. Do not despair. By using the ideas in successive chapters
and examples you will soon become familiar with them. To start with try
three fundamental, but by no means unimportant, exercises.
1.1 Using this chapter and the documentation for your SIMULA system,
compile and run our example. Note carefully the printed output from the
compiler and what files are produced by it.
1.2 Nearly all compilers allow you to produce a printed listing of
your program when it is being compiled. Most will allow you to specify
things about the appearance of this listing, for instance whether the
lines will be numbered for you and whether a cross referenced index of
identifiers is to be appended. Try producing listings using any options
available on your SIMULA system.
1.3 Try exercise 1.1 again changing the source program by:
Note carefully the differences in messages from the compiler and
when running the program in each case. See if the listing is different
when messages are printed by the compiler.
begin
integer Int1;
comment The first SIMULA program written for this book;
Int1:=3;
OutInt(Int1,4);
OutImage
end
begin end
A note on letters and "cases".
Although the programs shown in this book use bothcapital letters, which are known
to computer programmers as "upper case" characters, and small, "lower case", letters.
You are free to use whichever case you prefer. A SIMULA program is
interpreted as if all its letters, which are not enclosed in double quotes,
were first converted to upper case. You can
even write BegIN or eNd.
The right ingredients
So we have to put begin and end. What about the text in between?
Declarations
In example 1.1, the first instruction after the word begin is a declaration:
integer Int1;
begin
integer Int1;
real Real1;
etc.
begin
integer Int1;
integer Count;
etc.
begin
integer Int1, Count;
etc.
Comments
The next line is a comment. It begins with the keyword comment, is followed by some text and ends in a semi-colon.
comment The first SIMULA program written for this book;
Statements
The other instructions in our example are all statements. They tell
the SIMULA system what it is to do.
What do we do with our program?
So now we have what we think is a legal SIMULA program.
Unfortunately it is on paper and whilst we know what it should cause to
happen, the SIMULA system cannot read from the page. How then do we get
the SIMULA system to obey our program?
Note:
The ability to compile and run SIMULA programs depends on having
access to a computer with a SIMULA system. If your computer
currently does not, you may be able to buy one, but they are not
available for all computers. The suppliers of those systems
known to the author are listed at the back of this book. If your
computer is not listed, write to SIMULA A.S.,
who may be able to help. Their address is given in the list.
Readers in the United Kingdom might wish to contact the author.
Summary
Each chapter will end with a brief summary of what the author thinks you should
have learned from it.
Exercises
When the author was learning to write programs, he was told the most
important rule, "There is no such thing as an armchair programmer". The
simplest exercise can often teach even an experienced programmer
something new. Avoid the temptation to miss out examples as they will
often lead on to the material covered in the next chapter.