5.1 designing register machines

5/1/jord/lecture.org

@@ -0,0 +1,121 @@
+* Lecture 9A: Register Machines
+we have a lot of ideas about big programs but there are still
+mysteries about how things work
+
+we are going to take some very simple lisp programs and translate them
+to hardware
+
+our "very simple program":
+#+BEGIN_SRC scheme
+  (define (gcd a b)
+    (if (= b 0)
+	a
+	(gcd b (remainder a b))))
+#+END_SRC
+
+this algo has well defined state vars, a and b, that contain the
+essence of the algorithm
+
+we have two registers, a and b. we need a way to
+  - store b in a
+  - compute remainder (primitive)
+  - test equality with zero
+  - have a temp register
+  - be able to store temp in b
+
+now we need a controller
+
+there was a time, like with the DEC PDP-6, where this was the literal
+implementation
+
+gjs in a jovial mood XD
+
+: (define-machine gcd
+:   (registers a b t)
+:   (controller
+:   loop (branch (zero? (fetch b)) done)
+:        (assign t (remainder (fetch a) (fetch b)))
+:        (assign a (fetch b))
+:        (assign b (fetch t))
+:        (goto loop)
+:   done))
+
+gjs remembers using ibm 7090 computers
+
+--> break
+
+we can now build machines that can handle iterative processes. what
+about machines that can process recursive processes?
+
+#+BEGIN_SRC scheme
+  (define (fact n)
+    (if (= n 1)
+	1
+	(* n (fact (- n 1)))))
+#+END_SRC
+
+we can only make the illusion of infinity and 
+  "illusion's all that matters"
+
+we can develop a stack to keep track of subsequent recursive
+computated values
+
+: (assign continue done)
+: loop (branch (= 1 (fetch n)) base)
+: (save continue)
+: (save n)
+: (assign n (-1+ (fetch n)))
+: (assign continue after)
+: (goto loop)
+: after (restore n)
+: (restore continue)
+: (assign val (* (fetch n) (fetch val)))
+: (goto (fetch continue))
+: base (assign val (fetch n))
+: (goto (fetch continue))
+: done
+
+"bang!"
+  -gjs
+
+"memory is el cheapo and people are expensive"
+  -gjs
+
+--> break
+
+gonna look at a more complicated algo, doubly recursive fibonacci
+
+#+BEGIN_SRC scheme
+  (define (fib n)
+    (if (< n 2)
+	n
+	(+ (fib (- n 1))
+	   (fib (- n 2)))))
+#+END_SRC
+
+: (assign continue fib-done)
+: fib-loop ; n contains arg, continue is recipient
+: (branch (< (fetch n) 2) immediate-ans)
+: (save continue)
+: (assign continue after-fib-n-1)
+: (save n)
+: (assign n (- (fetch n) 1))
+: (goto fib-loop)
+: after-fib-n-1
+: (restore n)
+: ;; (restore continue) ;; not necessary
+: (assign n (- (fetch n) 2))
+: ;; (save continue) ;; not necessary
+: (assign continue after-fib-n-2)
+: (save val)
+: (goto fib-loop)
+: after-fib-n-2
+: (assign n (fetch val)) ;; fib(n-2)
+: (restore val) ;; restores and saves always match
+: (restore continue)
+: (assign val (+ (fetch val) (fetch n)))
+: (goto (fetch continue))
+: immediate-ans
+: (assign val (fetch n))
+: (goto (fetch continue))
+: fib-done.

5/1/jord/notes.org

@@ -0,0 +1,71 @@
+Chapter 5: Computing with Register Machines
+
+we have so far studied processes in lisp with successive models:
+  - substitution	    (ch 1)
+  - environment		    (ch 2)
+  - metacircular evaluator  (ch 4)
+
+but still we don't know how it works deep down, at the machine level
+
+a computer is really a /register machine/
+that sequentially executes /instructions/
+on some storage elements i.e. /registers/
+
+a register machine applies a primitive operation to the contents of
+some registers and assigns the result to another register
+
+we will approach this study from the perspective of a hardware architect
+
+* 5.1 Designing Register Machines
+we need two elements to design a register machine:
+  - data paths :: registers and operations
+  - a controller :: to sequence the operations
+
+algorithm analysis (1.2.5's euclid algo):
+#+BEGIN_SRC scheme
+  (define (gcd a b)
+    (if (= b 0)
+	a
+	(gcd b (remainder a b))))
+#+END_SRC
+
+** 5.1.1 a language for describing register machines
+the controller is a sequence of /instructions/ with /labels/ that
+define /entry points/ in the sequence
+
+** 5.1.2 abstraction in machine design
+we are assuming a lot here, hiding a lot of complexity in
+primitives. this is good though bc it allows us to think about design
+in other parts of the system
+
+** 5.1.3 subroutines
+we'd like to share components rather than duplicating them. we can do
+this by sharing registers. a better way is to have the 'continue'
+register hold the label of the entrypoint so that computation can
+continue after processing
+
+** 5.1.4 using a stack to implement recursion
+the register machine so far can compute any iterative
+procedure. consider the following algorithm (from 1.2.1)
+#+BEGIN_SRC scheme
+  (define (factorial n)
+    (if (= n 1)
+	1
+	(* (factorial (- n 1)) n)))
+#+END_SRC
+we have to solve for recursive execution
+
+** 5.1.5 instruction summary
+: (assign r (reg r))
+: (assign r (const r))
+: (assign r (op p) x ... )
+: (perform (op p) x ... )
+: (test (op p) x ...)
+: (branch (label n))
+: (goto (label n))
+: 
+: (assign r (label n))
+: (goto (reg r))
+:
+: (save r)
+: (restore r)