Transcript MacLennan Chapter 1 The Beginning: Pseudo-code Interpreters

MacLennan
Chapter 1
The Beginning:
Pseudo-code Interpreters
History and Motivation
• Programming is difficult.
– Because of its complexity, dealing with many different
details at one time.
• Programming early computers was especially
difficult.
– Very little storage, slow, complicated programming
– Four address, optimal coding, drum head
• Many program design notations were developed.
2
• Floating point and indexing were simulated.
– It was very difficult.
• 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
• 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
• A computer with 2000 words of 10-digit
memory
• We want facilities as:
– Arithmetic
– Control of execution flow
– Input-output
9
•
•
•
•
•
Floating-point arithmetic
Floating-point comparisons
Indexing
Transfer of control
Input-output
10
• 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
• 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.
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.
• We can describe mn 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.
– If there are lots of 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
• +0 for move
• (why +0 and not +6 ?)
• Easy-to-remember series of operations
– Move,add, multiply,square
– 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
• 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.
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
+9999999999
Input data
34
• An example, page 20
35
Implementation
• Automatic Execution is patterned after
manual execution
36
•
1.
2.
3.
4.
The read-execute cycle is the heart of an
iterative interpreter
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 Initialdata 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
• Fixed format statements
• ….
• Example in page 32
53
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.
54
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
55
Conclusion
• Pseudo-code interpreters simplified programming
– A virtual machine:
• more regular, higher level (abstract, automated), more secure,
simplify debugging
• Floating-point hardware made interpreters
unattractive
– 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
56
Exercises
•
•
•
•
•
•
•
•
1-15
1-17
1-18
1-26
1-29
1-35
1-37
1-40
57