CS225,  Fall 2006, Friday, Dec.1, Day 40  after class

HW Day 40, Due Monday Day 41   (2 class days after today) 
Reading:
Warford, Operating system & process management: 8.1, 8.2 thru p. 396.  Then 8.3 thru p. 421.  Storage Management 9.1,  thru p. 456.

A) Continue with programming. 
Presentation to the world, Friday, Dec. 8, (in Study Week.) Time 12-1,    We will NOT be reworking any more code in class.
Post on the Wiki ASAP,  what you have working (however simple); or if not, something whose bugs you can't solve.
Have ready to hand in, Last class or at Presentation, printed out:
your code, cover pages (Sub documentation. Algorithm if not obvious), Self-evaluation (modified 11/27)

Amnesty extended again:  Any  old "Programs" handed in  by last day of classes will be only 1 day late.
More extra credit:  Investigate another (simulated) assembly language/architecture  Well, the simulator doesn't work... Link

HW from Warford: Due Monday
A) Variable-partition Multiprogramming: Using the 48KB  available memory of fig. 9.3 (p. 451), Draw  the sequences for best fit and first fit algorithms (like  figures 9.5 and 9.7, for this job execution sequence-->
Assume no compaction.  Make a process wait till something else stops. if there's not enough space for it.
B)  In Program ZZZ, the logical address of the instruction ASLA is 00A1. The program  is loaded into the partition whose first address is 0C00. What  is the physical address of ASLA?
 Job   Size   Action
J1   12    Start
J2     4     Start
J3    4      Start
J4    16     Start
J2     (4)    Stop
J5     8      Start
J6      8     Start
J7      4     Start
J1    (12)   Stop
J4    (16)  Stop
J8     8      Start
J5     (8)    Stop
J9     12    Start
J10    4      Start

= = = = = = = = = = = == = = = =
Notes:
TICTACTOE:
 Program specifications:  It is crucial  as a programmer to
1) understand exactly what the specifications are,  (not clear? ASK!) and
2) make  your program do  exactly what the specifications require.
 It may be that what was specified is not  what was really wanted.  A clear and careful program meeting the (wrong) specs may help the designer clarify what he/she actually wants.  Part of the programmer's job is to help the designer make the specs clear, both before, and during, the program development.
This is a response to the fact that Winner turned out to be a Word-sized object when it is "naturally" a byte-sized one.

Refinement:
Performance specification : what the program is supposed to produce given certain inputs.  (Black box)
Program specification:  may include how certain parts of the program do their jobs (algorithms).    Often the designer (buyer) doesn't (want to) know what's inside.  Then specifications may be fuzzy, incorrect.

Commenting:  Clear comments are almost as important as correct code.  Especially when the code is as obscure as assembly language.
Test data:  Creating appropriate data to test your program is very important.
Test all conditions, if there are choices in the program.
Boundary values, the edges between decisions, countings, etc. are crucial.
Largest possible, smallest possible acceptable nuimbers.  Caps or small?
"Illegal" input: The specifications may say what input the program is supposed to handle.  What happens if it gets something out of that set?  It is useful to know what the program's response is.  Then you can decide whether/how the program should be modified to cope with that illegal input.

Von Neumann architecture:
Repeat: {Fetch instruction, Decode, Execute}  "Von Neumann bottleneck": one instruction at a time.  One cook in the kitchen.
    CPU has to do this in smaller steps, each taking one or more clock cycles.
 Repeat:  {Fetch opcode, Decode opcode, (Calculate effective address of operand(s!), Fetch operand(s!)), Execute(multiple steps?), Store result}

Ways to ameliorate the one-cook bottleneck:
Shorten maximum clock time per instruction: 
Pipelining: N&L 216-17, 478   "Everybody" uses it now...
Other problems: If Fetch, Load/store use same bus to transfer: conflicts?  Load a data item  before it's been stored from previous op?

More parallelism:
Multiple processors:  e.g. separate processor for floating point arithmetic (early); for graphical output, for other I/O. Or  2 or more of the "same" processor running at the same time ("Dual" processors).  Issues:  How to manage use of common memory (if there is common memory),   who does what instructions (obvious for special purpose processors, not for parallel ones), waiting for stuff.
Distributed computing:  "Separate" computers networked, working on a common problem.

BACK TO:
Operating system:  What does it have to do, and how (a little) does it do it?  Warford, Ch. 8, lightly.  8.1, beginning 8.2
   First job:  Load a program and turn control over to it:  (PEP8)
       Loader: Is a subroutine in the operating system.  Load button puts its first instruction address in PC.
           Copies the program into memory starting at 0000,
               puts FBCF into SP
               puts 0000 into PC,
                  next instruction to run is the one at 0000.
   Our programs STOP.  In a "real" system, control would revert to the operating system, which would load another program, never (rarely) stop.

Trap:  (similar to "interrupt"--language varies)  Like subroutine but part of operating system.  DECI, DECO, STRO are traps in PEP8.
   Need to leave the running program, execute the trap, return, invisibly except for desired effect.
Process Control Block  on entering the trap, all info about the running program (process) is saved into memory in this block.  (On system stack or special memory blocks).  Restored at return from trap. 
What?  All Registers! (including Flags, Stack Pointer, PC).  That contains all info needed to pick up where we left off (unless memory has been messed with in a wrong way...)

Continue Ch. 8:
Single process:  Op. Sys. loads and starts process (running program), yields control until process
   --terminates
   --causes trap =software interrupt like DECI,
Process control block:   "state of computer" at time of interrupt: all registers and flags, placed on system stack, so process can be restored at end of interrupt.  (Like a stack frame for procedure but of registers and flags)

Synchronous interrupt (trap):  Happens at the same time in any run of the program: e.g.
         call for I/O, or SVC (service) call for op.sys. to act.  "software interrupt"

Asynchronous interrupt:  Not at a predictable time.
-- I/O  is complete (character has been typed, character has been output to screen, etc.)  I/O not on the same "clock" as main processor.
      Single process operation, we just wait ...
--Time outs:  Make one process wait while we run part or all of another process.
That is, do
Multiprogramming Concurrent processes: (Not really concurrent, really interleaved, but "feel" concurrent to the outside)
time sharing:  Each process gets a Process ID.  Allot a time slice to each process.  If it isn't done,  put its Process Control Block (and time used so far) on a (sort of) queue.  Run the next process.  Etc.  If a process is waiting for I/O, run another till the first's I/O comes back.            Fig. 8.19
P. 372  While running...1)  Timeslice alarm clock can interrupt.  (Timeout)  (To Ready queue)
    2) Can finish running.  (SVC to op sys to terminate)
    3) I/O call: SVC to op sys, which makes request to  I/O and puts process on waiting-for-I/O queue.  (When I/O returns, ops sys sends data to buffer, process to Ready queue)

(Decisions can be made on length of time process has already run (or potential length of time), about whether to continue or timeout)

Multiprocessing:  More than one CPU sharing other resources, esp. memory.  No problem except when resources need to be shared, synchronized.
  (e.g. in TTT, could farm out DisplayB to one processor, CkWin to another; starting at the same time.  But then result from CkWin gets analyzed; rest of sequence can't proceed till DisplayB is done.)  Rest of Ch. 8 = problems and solutions to resource sharing.

Chapter 9: Storage management
9.1: Main memory  Increasingly complex techniques, each solving another problem.  (First 9.1,  thru p. 456.  Then more?)
1) Uniprogramming:  For single process.  Pep8.  Load user program in at (say) 0000.  (Op sys at the other end.)
  Useful for embedded systems:  clocks, calculators, service alerts from refrigerator....
    Problem:  Everyone wants to multiprocess.  E.g.Windows.

Multiprocessing techniques--load several processes into memory, switch among them (using PCB's to preserve process)
2) Fixed partitions:  Divide available memory up into chunks, of varying sizes (big to little) and put programs into appropriate size partitions.  (e.g. chunks,  2 of 4-Kb, 1 8-Kb, 1 32-Kb)
Needs:  Loader must be relocatable. Code must be relocatable. (Addresses won't be "correct" as written)
  Relocatable techniques: 
       1) build in to Assembler:   .ORG h#8000,  originate program at address 8000 --one of the partition beginnings.
  and/or   2) (not in text)  Make (almost) all branches "relative"--jump n addresses back/forward from the present address.
  or   3) logical address Generate the object code as if it will be loaded at 0000.  This gives "logical addresses" for everything. 
                    Physical address = logical address + partition address
                         Op. sys. software to manage, or      
            Special registers for the partition:  Base register (holds partition address = bottom address of the partition)
                     Bound register (holds upper bound of this partition.  Keeps program from overwriting allowed space)
            (Logical address is like index, offset from Base address of partition)
Problem: Our fixed partitions may not suit the incoming programs (2 large& no small, or  6 small programs)

3) Variable partitions:  Load the program in as it comes, make a partition just big enough for it, load the next one after it, etc.
(Need relocatable techniques still)
Needs:  What when you've filled up memory from beginning to end?  After it's been going a little, some program near the beginning finishes, leaves a hole.  Then another hole, etc.  Not usually together. How to allocate when memory is fragmented?
  Best-fit:  Choose the hole which holds your program, and is the smallest available which will.
  First-fit:  Choose the first hole (counting from beginning, 0000)  Works better than you'd think--large holes tend to accumulate toward the end.
  Compactify:  Not enough contiguous space for next program? Shift everything (or some things) toward beginning, consolidating in-use and combining holes.  (Time consuming!)

4) Paging:  ("paged memory")  Instead of adjusting the partitions to different sizes to fit the programs, break the memory into even size chunks (frames),  and break the program into pages (each the size of a frame).  Program pages get stuck into next available frames, not necessarily contiguous. 
Needs:  For each process:  1) keep track of where each page is (Page table).   
             Process 1:   Page     is in   Frame
                                    1                   3
                                    2                   8
                                    3                   4
                  2) Translate logical to physical addresses.  Need to know what page the instruction is on. 
                        Logical address = Page base address + offset
                            Page number<-->Frame number.
                      Physical = offset + Frame base address
            Efficient way to do this in the computer: 
                 Make  page/frame size  a power of 2 (say 1 Kb) .
                     then logical address "splits'" at that place into page number + within-page address (offset).
                  1Kb: 1024 = 210 addresses:  00 0000 0000 to 11 1111 1111  are the within-page addresses.
                         If we allow 26  pages, possible page/frame numbers are 0000 00 to 1111 11.
                  Logical Address 5D on page 3 is then 0000 11+00 0000 0101, or 0C05H 
                          Since page 3 is in Frame 4,  
                             to get the Physical address we substitute the frame number for the page number, 0000 11-->0001 00
                                  Physical address is 0001 00+00 0000 0101, or 1005H
          
  For op sys :   For each frame,  Keep track of which process and page is there--or empty.
      While program is running, every memory reference has to go through the page table. (at least if you're changing pages)

Problem:  Still some "internal fragmentation" --unusable space--because programs don't fill out the last page they use.  Unavoidable tradeoff:  Smaller page size cuts unusable space but increases overhead of managing larger page tables.  Faster circuitry for page table means more expense for larger table.

Problem:  Large programs may not fit into memory. 
   Solution 9.2: Virtual Memory

, To Sievers Home Page
CS225-Fall06/Day40.htm 
1pm, 12/3/06
This page belongs to Sally Sievers who is solely responsible for its content. Please see our statement of responsibility