Elements of Computing Systems Chapter 4

12 of us met to discuss chapter 4 of Elements of Computing Systems on Tue 13th Jan 2015, with Chris L. and others bringing a suitably eclectic selection of snacks including mince pies.

Preamble

This was the very last meeting in Go Free Range HQ 2.0 which has been host to all of the previous 25 meetings of London Computation Club (in our admittedly revisionist history). This made it seem fitting that we began with a thank you to James Mead and Go Free Range for all they've done to make us feel welcome.

Then followed the difficult task of selecting a venue for our next meeting. A number of people very kindly offered their offices as potential locations all of which looked like possibilities. A number had significant drawbacks (FutureLearn and Macmillan's offices both look like security requirements will make them less convenient to use, and Unboxed's offices would require us to move to a different day of the week).

We agreed that Leo's offer of Geckoboard's offices seemed like the best for now (good facilities and simple to access) and so, pending Leo's confirmation that this is definitely possible, our next meeting will be at Geckoboard.

Review of the chapter

Having got the preliminaries out of the way we reviewed Chapter 4.

In fact, just as we say that the machine language is designed to exploit a given hardware platform, we can say that the hardware platform is designed to fetch, interpret, and execute instructions written in the given machine language.

There was some discussion of why the memory address space had been split into two (1 read only space and 1 read/write space). Various theories were put forward including

1. the read only memory is containing the program avoids us having to work out how the data got there in the first place and...
2. this means that both address spaces start from 0 simplifying decisions about where can be written too

Also the book said that this was a "von Neumann platform", which didn't match our understanding where avon Neumann architecture is one in which the program is in a single read/write space with data whereas a Harvard architecture would have two separate spaces.

Projects

We were happy with our understanding of the chapter and so moved on to the projects with James M. valiantly taking the keyboard and translating our various thoughts into code.

We looked at implementing multiplication in HACK and agreed on a repeated addition strategy. Firstly we used pseudo-code in comments to outline our approach. We then filled in the details and it was pleasantly surprising (for me) and very satisfying when we reached our first working version.

We noted that HACK has no support for programs finishing and you are expected to put the program into an infinite loop in order to signal that you have stopped (the tests assume check output after a fixed number of steps).

We optimised the program slightly by setting a register to R0 at the end of the loop and avoiding resetting it thus moving two of the instructions outside the loop.

Finally we looked at the fill exercise which has input (keyboard) and output (screen).

There was some discussion of mapping of key combinations onto ASCII codes before we got going. Also the exercise was not specific about whether pressing/releasing a key would change the colour mid cycle through the screen but we decided that in our program it would.

We took the same approach of writing increasingly detailed pseudo code in comments before actually implementing in one fell swoop. This program seemed more fiddly than the last, mainly because of the amount of shuffling into and out of the registers.

We made two clear mis-steps that we had to correct. The first of which was remembering to dereference the screen counter twice in order to write to the screen memory and the second was around ensuring we spotted when we needed to loop back to the beginning of the screen. Having debugged these issues we had this code

At this point, after plenty of fiddling with the CPU Emulator, we found our program only seemed to turn a single pixel at the top left hand side of the screen on and off. After lots of attempts to debug this including running the program and seeing all the addresses corresponding to the screen being set to -1 (All bits are 1 in two's compliment representation, which should be sixteen black pixels in this case) we were suspicious there was a problem with the Emulator itself. We tested this by running the program that James had written ahead of the meeting and found this was broken in the same way increasing our suspicion. Some of us were clearly loathed to leave GFR HQ 2.0 for the last time and a number of people persisted for the best part of an hour trying to resolve this before finally giving up.

After we'd all headed home James reinstalled Java and found this fixed it. He also posted this video as proof. W00t!

All in all a thoroughly enjoyable meeting, despite the sadness of leaving GFR.

Next stop chapter 5.