1. MacLennan Chapter 1 The Beginning: Pseudo-code Interpreters

2. 2 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.

3. 3 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.

4. 4 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.

5. 5 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.

6. 6 Programming languages can be viewed as defining virtual computers. –Better in some respects –Usually slower

7. 7 Compiling Routines Extract subroutines from libraries and combine them (compiling). Less overhead, is done once. Will be discussed in following chapter.

8. 8 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.

9. 9 A computer with 2000 words of 10-digit memory We want facilities as: –Arithmetic –Control of execution flow –Input-output

10. 10 Floating-point arithmetic Floating-point comparisons Indexing Transfer of control Input-output

11. 11 How large shall the addresses be? –Two, three, or four? –Two: 100 locations –Three: 1000 locations –Four: 10,000 locations

12. 12 Three digits: –Addressing only 1000 locations  security –First 1000 locations for data –We are unable to address out of data area

13. 13 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.

14. 14 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

15. 15 Instructions have three operands. op opn1 opn2 dest +1 010 150 200 add …

16. 16 Encoding of operations: +- 1+- 2*/ 3squaresquare root

17. 17 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

18. 18 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!

19. 19 Orthogonality may be inappropriate. –If there are lots of exceptions.

20. 20 We need comparison to alter control flow +- 1+- 2*/ 3squaresquare root 4If = gotoIf <> goto 5If>= gotoIf < goto

21. 21 +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

22. 22 Moving Do we need a ‘moving operation’? +1 150 000 280 [150]  [280] But this is slow!

23. 23 +0 for move (why +0 and not +6 ?) Easy-to-remember series of operations –Move,add, multiply,square –Application of Regularity Principle

24. 24 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.

25. 25 What operation(s) shall we define on arrays? Move them to or from other locations +6 xxx iii zzz x i  z -6 xxx yyy iii x  y i

26. 26 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

27. 27 Initialize, increment, and test index variables We can use instructions which already exist, but –They are floating point operations –Indexing is used very often

28. 28 The Abstraction Principle Avoid requiring something to be stated more than once; factor out the recurring pattern. It is a corollary of Automation Principle.

29. 29 +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

30. 30 +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,

31. 31 Input-Output +8 Read a card containing one 10-digit number into a specified memory location. -8 Print the contents of a memory location

32. 32 Pseudo-Code operations table Page 19

33. 33 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?

34. 34 Program Structure +9999999999 Initial data values Program instructions Input data (Declarations)

35. 35 An example, page 20

36. 36 Implementation Automatic Execution is patterned after manual execution

37. 37 The read-execute cycle is the heart of an iterative interpreter 1.Read the next instruction. 2.Decode the instruction. 3.Execute the operation. 4.Continue from step 1 with the next instruction.

38. 38 Where shall we add IP := IP + 1 ?

39. 39 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.

40. 40 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.

41. 41 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

42. 42 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.

43. 43 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

44. 44 +0 666 150 000 +3 141 592 654 Declares a 150-element array, identified by the label 666, Initialized to all +3141592654

45. 45 +0 111 001 000 +0 000 000 000 A simple variable, labeled 111, is declared and initialized to zero.

46. 46 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.

47. 47 Loader also is doing: storage allocation

48. 48 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 +?

49. 49 Classes of Binding Times Execution time Translation time Language implementation time Language definition time

50. 50 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.

51. 51 The Security Principle No program that violates the definition of the language, or its own intended structure, should escape detection. C.A.R. Hoare

52. 52 The idea presented here are easily extended to a symbolic pseudo-code. Declare declarations Begin statements End;

53. 53 Fixed format statements …. Example in page 32

54. 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. 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. 56 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

57. 57 Exercises 1-15 1-17 1-18 1-26 1-29 1-35 1-37 1-40