Week 3 notes

Readings (from BOH3)

Section 2.1 (you can skip 2.1.7 for now, on bitwise operations, and 2.1.9 on shift operations)
Section 2.2 (don't sweat the B2Uw notation for now, though all it's doing is formally defining the conversion from strings of bits to integers)
Section 2.3 on integer arithmetic (we'll save floating point, in 2.4, for later)

How to start a program on boole.

I created a program pldcp and installed it on boole. It takes a file (or files) in my top-level directory and copies it (them) to your current directory. So if you want to copy my hello.c file, as a starter, you can simply run pldcp hello.c. (You can also just copy directly, with cp /home/pld/hello.c ., where . is a shorthand for your current directory.)

C: see c.html

rows_and_columns.c: an illustration of the effect of caches. Row order and column order visit exactly the same array components, but in different orders.

branchpredict.c: an illustration of the effect of branch prediction. The two array passes -- before and after sorting -- do exactly the same work, just in different orders. Also, what's with that 'µ'? Is it a byte?

Monday 1/28:

endian.c

demos of char * p, strlen(), strcmp(), strcpy()

More on array/pointer duality

endian.c

What does the program do? What happens if we get rid of the unsigned? Why "%02x"?

Advantages of little-endian byte order

Above is 65536+24 = 65560, in little-endian byte order. As hex, it is 0x00010018 (why?).

Little-endian amounts to thinking of the number in base 256 (that is, as four full-byte units), and writing them right to left. Why would you do that?

Possible reason one: on 8-bit systems, where you load one byte at a time, if you want to add two 32-bit quantities you can start as soon as the first byte is loaded. On big-endian systems you have to wait for the last byte to be loaded before you can start doing arithmetic. (But you could also create opcodes such as "load low-order byte of 32-bit word pointed to by register r1")

Possible reason two: if p is a pointer to the above, so p points to the low-numbered byte, that is, the lefthand one, then p points to:

• the 32-bit quantity shown above
• the 16-bit quantity 0x0018
• the 8-bit quantity 0x18

There are times when this is a convenience, again, probably mostly for very simple CPUs. There are similar, but kind of technical, advantages for big-endian byte order. There is also one large programmer benefit for big-endian: numbers printed in memory dumps look the same way they do when written ordinarily. This makes that kind of debugging quite a bit easier. That said, today debugging from hex dumps is relatively rare. (I still do it when examining network packets, though.)

Friday

questions about the program(s)

arrays.c

char A[] = "hello";
char  *p = A;
for (int i=0; i<strlen(p); i++) putchar(p[i]);
for (int i=0; i<strlen(A); i++) putchar ( *(A+i))

One more array weirdness and I'll change the subject. A[i] is the same as *(A+i). Which should be the same as *(i+A). Which is i[A]. But don't use this.

time1.c
rows_and_columns.c