CS 111 Lecture 3 Notes: 10/7/13

Andrew Shih, Roger Lee



Ways to Improve Program

  1. Go faster
  2. Increase block size

    3. Batching lessens overhead
    (but not so much that you trun out of memory)
    (wasted work for small files)
    (but keep it in cache)

  3. Overlay I/O with computation
  4. PIO --> DMA (direct memory access)



Real Problems with our program

What is usually the problem with our code?



Goal: Make useful improvements one module at a time

Effect of modularity on bug-finding:

The cost to fix the problem is proportional to L*B/M



I/O vs Computation

Overlapping I/O and computation were significant gains when you have a balanced system. (I/O and computation take about the same time)

Abstraction

"Metrics" for quality of modularization:



Mechanisms for modularity

"Metrics" for quality of modularization:

  1. None (write whatever you like)
  2. Function calls (soft modularity)
    3. We want hard modularity because it protects modules from each other



Review of Assembly code

Lets look at a recursive factorial function: 

					int fact (int n) { 
						if (n == 0) 
							return 1; 
						return n * fact(n-1); 
					}
In assembly, this turns into:

Assembly code: C style assembly:
fact: pushl %ebp *--sp=bp;
movl $1, %eax ax=1;
movl %esp, %ebp bp=sp;
subl $8, %esp sp=8;
movl %ebx,-4(%ebp) bp[-1]=bx;
movl 8(%ebp),%ebx bx=bp[2];
tstl %ebx,%ebx if (n!=0);
jne L5 goto L5;
L1: movl -4(%ebp),%ebx bx=bp[-1];
movl %ebp,%esp sp=bp;
popl %ebp bp=*sp++;
ret i=*sp++;
L5: leal -1(%ebx),%eax ax=bx-1;
movl %eax,(%esp) *sp=ax;
call fact *sp++=ip;
imull %ebx,%eax ax*=bx;
jmp L1 goto L1;

What can go wrong?
  1. Hard to change conventions-complete recompilation
  2. Callee can stomp on caller's storage or caller's caller
  3. Caller isn't insulated from callee disasters
  4. Caller can mess up callee
  5. Callee can loop forever



Hard modularity

Main techniques

  1. Client-Server (peer-to-peer):
    2. Two machines communicate through Send/Receive
    (Very nice hard modularity but slow)
  2. Virtualization:
    3. Write x86 emulator for coe that you don't trust. Have the caller run on an emulator (trusted, but with boundaries). This holds the problem for infinite loops.
    This is still too slow, but it is virtualizable hardware!
    Emulated code runs at full speeed but in a sandbox. Hardware traps if you run a dangerous instruction such as HALT, INB,...etc. (privileged)
  3. Protected transfer of control:
    4. Callee is protecte from caller
    Runs a lot faster!