MacLennan
Chapter 1
The Beginning:
Pseudo-code Interpreters
History and Motivation

Programming is difficult.


Programming early computers was especially
difficult.




Because of its complexity, dealing with many
different details at one time.
Very little storage, slow, complicated programming
Four address, optimal coding, drum head
Irregular and hardware based op codes
Many program design notations were
developed.
2



Floating point and indexing were simulated.

It was very difficult.

Development of floating-point subroutines: slow but simple
Pseudo-code Interpreters were invented.
Pseudo-code Interpreters implemented a
Virtual computer with its own set of data
types (floating point) and operations (indexing) in
terms of the real computer with its own
data types and operations.
3
The Automation Principle
Automate mechanical, tedious, or
error prone activities.

The virtual computer is in a higher level
than the real one.


Provide more suitable facilities.
Eliminate many details.
4
The Regularity Principle
Regular rules, without exceptions,
are easier to learn, use, describe,
and implement.


The virtual computer is more regular
than the real one.
Simpler to understand through the
absence of special cases.
5

All programming languages can be
viewed as defining virtual computers.


Better in some respects
Usually slower
6
Compiling Routines



Extract subroutines from libraries and
combine them (compiling).
Less overhead, is done once.
Will be discussed in following chapter.
7
Design of a Pseudo-code


Similar to real pseudo-codes, languages
L1 and L2, Bell Labs, for the IBM 650,
in 1955 and 1956.
Goal: Illustrating many of the steps and
decisions in design of a programming
language.
8
Assumptions and Facilities


A computer with 2000 words of 10-digit
memory
We want facilities as:



Arithmetic
Control of execution flow
Input-output
9
Functions





Floating-point arithmetic
Floating-point comparisons
Indexing
Transfer of control
Input-output
10
Make a decision

How large shall the addresses be?




Two, three, or four?
Two: 100 locations
Three: 1000 locations
Four: 10,000 locations
11

Three digits:

Addressing only 1000 locations  security
First 1000 locations for data
 We are unable to address out of data
area

12
The Impossible Error
Principle
Making errors impossible to
commit is preferable to detecting
them after their commission.

With our addressing rule, we prevent
the programmer to overwrite program
or the interpreter.
13
Next decision

The instructions could have two, three,
or four operands.



Two addresses:
x+y  x
Three addresses: x+y z
Four addresses: x+y*z  w
14

Instructions have three operands.

Encoding of 20 operations is possible
op opn1 opn2 dest
+1 010 150 200
add …
15

Encoding of operations:
+
-
1
+
-
2
*
/
3
square
square root
16
The Orthogonality
Principle
Independent functions should be
controlled by independent
mechanisms.


A corollary of regularity principle.
We can describe m*n different
possibilities even though we only have
to memorize m+n independent facts.
17
Design Principles must be applied
flexibly



Some of the principles contradict one
another.
A balance must be find.
No rules for this balancing task

Experience gives you a good eye!
18
Orthogonality may be
inappropriate

Some of m*n possibilities may be:



Useless
Difficult to implement
Illegal
Remember these as exceptions.
19

We need comparison to alter control
flow
+
-
1
+
-
2
*
/
3
square
square root
4
If = goto
If <> goto
5
If>= goto
If < goto
20


+4 200 201 035
If [200] = [201] then goto 035




Data location 200,201
Program location 035
-5 702 000 100
If [702] < 0 then goto 100
21
Moving

Do we need a ‘moving operation’?

+1 150 000 280
[150]  [280]

But this is slow!

22
Moving



+0 for move
(why +0 and not +6 ?)
Easy-to-remember series of operations:


Move, add, multiply, square (increasing
complexity)
Application of Regularity Principle
23
Indexing and Loops

We need



Address of the array
Address of the index variable
So, we used two of the three address
fields in the instruction.
24




What operation(s) shall we define on
arrays?
Move them to or from other locations
+6 xxx iii zzz
xi  z
-6 xxx yyy iii
x  yi
25
Examples for indexing





We have a 100-element array beginning
at location 250 in data memory, and
location 050 contains 17,
+6 250 050 803
Move [267] to 803
-6 722 250 050
Move [722] to 267
26
Loops


Initialize, increment, and test index
variables
We can use instructions which already
exist, but


They are floating point operations
Indexing is used very often
27
The Abstraction Principle
Avoid requiring something to be
stated more than once; factor out
the recurring pattern.


It is a corollary of Automation Principle.
Results to the appearance of modules.
28


+7 for increment and test indices
We need to know



The location of the index
The location of the upper bound for the
loop
The location where the loop begins
29

+7 iii nnn ddd




iii : address of the index,
nnn : address of the upper bound,
ddd : location of the beginning of the loop
[iii]+ +; if [iii] < [nnn] then go to
ddd;
30
Input-Output




+8
Read a card containing one 10-digit
number into a specified memory
location.
-8
Print the contents of a memory location
31
Pseudo-Code operations table
Page 19
32
Program Structure



How do we arrange to get the program
loaded into memory?
How do we initialize locations in the
data memory?
How do we provide input data for the
program?
33
Program Structure
Initial data values
(Declarations)
+9999999999
Program instructions
(executable statements)
+9999999999
Input data
34

An example, page 20
35
Implementation



Automatic Execution is patterned after
manual execution
Iterative interpreter
Recursive interpreter
36
The read-execute cycle is the
heart of an iterative interpreter
1.
2.
3.
4.
Read the next instruction.
Decode the instruction.
Execute the operation.
Continue from step 1 with the next
instruction.
37

Where shall we add
IP := IP + 1 ?
38

Interpreters simplify debugging.


Add an instruction to the interpreter to get
a trace of the execution of the program.
Statement labels simplify coding.

Using absolute locations in pseudo-code
instruction, make changes error-prone and
tedious.
39
The Labeling Principle

Do not require the user to know
the absolute position of an item in
a list. Instead, associate labels
with any position that must be
referenced elsewhere.
40
Label definition operator





-7 0LL 000 000
It is a non-executable statement.
It is a declaration and say bind a
symbolic label to an absolute location.
So we will have: +4 xxx yyy 0LL ,
Look at page 27
41
How can we interpret labels?


Label tables
We have to know



all the labels are defined once,
if there is any referencing to undefined
labels,
if a label is defined in more than one place.
42
Variables can be processed
like labels




We can have variable declarations in
Initial-data section of the program:
+0 sss nnn 000
d ddd ddd ddd
Declare a storage area with symbolic
name sss, nnn locations long, initialized
to all
d ddd ddd ddd
43
+0 666 150 000
+3 141 592 654
Declares a 150-element array,
identified by the label 666,
Initialized to all +3141592654
44
+0 111 001 000
+0 000 000 000
A simple variable, labeled 111, is declared
and initialized to zero.
45


For each declaration, the loader keeps
track of the next available memory
location, and binds the symbolic
variable number to that location.
Binding time of the declaration is load
time.
46

Loader also is doing:
storage allocation
47
Binding times?

X:=X+10






Value of a variable?
Type of X?
Valid range of values for a variable (a
type)?
Set of possible types for variable X?
Representation of the constant 10?
Properties of operator +?
48
Classes of Binding Times




Execution time
Translation time
Language implementation time
Language definition time
49

The interpreter can record in the
symbol table the size of the array and
so,can check each reference to the
array.
=> Prevents a violation of the program’s
intended structure.
50
The Security Principle
No program that violates the
definition of the language, or its
own intended structure, should
escape detection.
C.A.R. Hoare
51

The idea presented here are easily extended
to a symbolic pseudo-code.
declare
declarations
begin
statements
end;
52
Implement a symbolic pseudocode




symbol table for operations and
operands
A program array for encoded instruction
The loader performs a translation
function
Tow stage translation process

Source form  intermediate form  machine
language
53



Fixed format statements
….
Example in page 32
54
The Labeling Principle
Do not require the user to know
the absolute position of an item in
a list. Instead, associate labels
with any position that must be
referenced elsewhere.
55
Programming Languages as
Tools

Tools are both amplifying and reductive




A stick to knock the fruit down, instead of your
hands
Fascination and fear are common reactions to
new tools
With mastery, you no more feel the tool as an
external, additional object
Programming languages influence focus and
action

Writing by pen, a typewriter, a word processor
56
Conclusion

Pseudo-code interpreters simplified
programming

A virtual machine:


Floating-point hardware made interpreters
unattractive


more regular, higher level (abstract, automated), more
secure, simplify debugging
Computer time was more expensive than
programmer time
Libraries led to the idea of compiling routines

Up to mid 1950: still important programming had
to be done in assembly language
57
Exercises







1-5
1-11
1-18
1-29
1-35
1-37
1-40
58