9/20/6Lecture 3 - Instruction Set - Al1 Program Design

9/20/6Lecture 3 - Instruction Set - Al2 Lecture Overview  Top down design  Modular design  Parameter Passing  Stack and Local Variables  Structured Programming

9/20/6Lecture 3 - Instruction Set - Al3 Top Down Design  Programming in assembler Assembler language does not intuitively result in good quality programs It takes special care to design quality programs  Five ingredients to good program design Top-down design Modularity Structured programming Testability Recoverability

9/20/6Lecture 3 - Instruction Set - Al4 Assembler Language  Greatest Challenge – Where to begin  Answer Don’t actually program in assembler Program in a program design language (PDL) and then translate from the PDL to assembler  Pseudo compiling  May even be desirable to write up the algorithm in a PDL and then translate to a high level language (HLL) Program the algorithm in PDL – much like any HLL

9/20/6Lecture 3 - Instruction Set - Al5 Top Down Design  Also called “Stepwise Refinement”  Iterative Process (ref Fig 3.1 of text)

9/20/6Lecture 3 - Instruction Set - Al6 Disk OS example Shows design along functional Lines.

9/20/6Lecture 3 - Instruction Set - Al7 Popular Approach to Programming  Approach is called Top-Down Design and Bottom-Up Coding.  Problem decomposed into levels of abstraction (top-down design)  System implemented by coding the lowest levels first (bottom-up coding)  EX: Word Processor – Code I/O of char first.

9/20/6Lecture 3 - Instruction Set - Al8 System Specification  Before system designed it must be specified  What is goal of system  Let us brainstorm on what is needed to implement a serial interface. Hardware wise Software wise TIME TO DO THE SPECIFICATION Suggest a system – create spec

9/20/6Lecture 3 - Instruction Set - Al9 Degree of Specification  Tightly specified – ultimately cover all possible eventualities  Loosely specified – situations may occur during operation which are not covered by spec.

9/20/6Lecture 3 - Instruction Set - Al10 Modular Design  Current software is modular in design.  Why? Overall less complex. – divided into subsystems and after levels of decomposition, leaf elements are simple. Leaf elements are called modules  Software module is analogous to a hardware element – has inputs, outputs and can be “plugged in”

9/20/6Lecture 3 - Instruction Set - Al11 Modules  Module Coupling How information is shared between one module and other modules of the system. Tightly coupled – modules share common data areas and both can modify the data.  When there is erroneous data hard to debug Loosely coupled – module has access to only its own data and not other process can access its data  Data transfers only through I/O interface

9/20/6Lecture 3 - Instruction Set - Al12 Modules  Module Strength A measure of its modularity Divide a large program up into units of ~75 lines each. Divide a large program up into units where each unit has a closed task.  Strong modules are easy to test as they only perform one function.

Assignment  Assignment HW 3 Problem 2-35 page For discussion in class  Time of execution – In class assignment for us to work HW4 – code the algorithm for reversing the order of the bits using your method vs. one given in class  Code this in the simulator. Use trap 15 with a value of 8 in register D0.L to get the time when execution of your program started (returned in D1), save it to another register. Do the same at the end and repeat the trap. Have your original data in one register ant the reversed in another. Capture and paste the simulator window into word. Make notes to specify the register used. Past the window, and then add your code. Fri Coming – code up your subroutine from /20/6Lecture 3 - Instruction Set - Al13