9/20/6 Lecture 3 - Instruction Set - Al 1

Program Design

9/20/6 Lecture 3 - Instruction Set - Al 2

Lecture Overview Top down design Modular design Parameter Passing Stack and Local Variables Structured Programming

9/20/6 Lecture 3 - Instruction Set - Al 3

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/6 Lecture 3 - Instruction Set - Al 4

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/6 Lecture 3 - Instruction Set - Al 5

Top Down Design Also called “Stepwise Refinement” Iterative Process (ref Fig 3.1 of text)

Program

Subtask t2Subtask t1

Subtask t1,1 Subtask t1,2 Subtask t1,3

9/20/6 Lecture 3 - Instruction Set - Al 6

Disk OS example

Shows design along functionalLines.

9/20/6 Lecture 3 - Instruction Set - Al 7

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/6 Lecture 3 - Instruction Set - Al 8

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/6 Lecture 3 - Instruction Set - Al 9

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/6 Lecture 3 - Instruction Set - Al 10

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/6 Lecture 3 - Instruction Set - Al 11

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/6 Lecture 3 - Instruction Set - Al 12

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 127 - 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 2-35

9/20/6 Lecture 3 - Instruction Set - Al 13