M/C Part 23

DIAGRAMS AND PSEUDO-CODE
------------------------

Oh please, don't groan. I know this sound awfully like a
computing lesson at school, but it is important. If you're
considering writing a program of any considerable length, you
should always sit down with a bit of paper and a pen first, and
design what you're doing. The most widely-used method is called
top-down design with stepwise refinement.

Now, I don't expect any of you to do this Open University style,
or to any great extent. I don't. But, the concepts are useful.
You start with the problem and split it into a number of simple
steps. Then, you take each step in turn and refine it further
into more steps. When using high-level languages like BASIC this
tends to lead to writing actual lines, but this is a bit of a
waste of time with assembly. Instead, your design (go as far as
you like - I do! (nat I mean??)) will help you know the routines
you need to write.

The two best ways of doing this design are Stucture Diagrams and
Pseudo Code. The diagrams are a little hard to explain here, but
simply:

* Commands (or groups of small commands) are put in rectangular
boxes:
                ________
               |________|

* Procedures go in rectangular boxes with double edges at the
left and right:
                 ______
               ||______||

* Decisions go in boxes with pointed ends:

                ________
               <________>

* Loops go in boxes with rounded ends:

                ________
               (________)

Any structures coming out of boxes are joined to the box with
straight lines. All of the lines appear from the same place.

The lines from decision boxes are labelled with the decision
that leads to them.

Note that this isn't a flow diagram: the commands are executed
along a level until a new structure is reached. The commands in
in are executed until finished, and control returns to the
previous level. eg.

                         _____________
                       ||             ||
                       || Simple prog ||
                       ||_____________||
       _______________________/\______________
 _____/____      _____/______           ______\_________
|          |    /            \         /                \
| Input    |   <  Number >0?  >       (  Do number times )
| number   |    \____________/         \________________/
|__________|          /\                       |
                  Y  /  \  N                   |
               _____/    \                     |
        ______/_____   ___\________        ____|_____
       |            | |            |      |          |
       | Print      | | Print      |      | Print    |
       | "Positive" | | "Negative" |      | "Wibble" |
       |____________| |____________|      |__________|

Get the idea? Well, another way of doing the same thing is to
write down the above diagram using indenting to show structure:

simple prog:     input number
                 number >0?
                       If yes, print "Positive"
                       If no, print "Negative"
                 Do number times
                       Print "Wibble"
                 End

Oh, and I know 0 isn't negative, okay?

Anyway, without going into the same kind of detail as that above
you can structure your code before typing it in. Any obvious
mistakes in design can be found by dry-running through the
diagram or psuedo-code manually with test data.

STUBBING
--------

Once the seperate procedures have been identified, you can type
them into your assembler one at a time. After writing the first
one, test it.

Ah, I hear you say, what about the routines it uses that I
haven't done yet? Well, you write a few lines for each, either
doing nothing or returning some data for the program. This dummy
procedure is known as a STUB. (have a look at the last article
for more info).

Once the module of code is tested, save it (only the necessary
line, not the stubs). You can now merge it safely into future
modules, full in the knowledge that it works.

To assemble the full program, or a main part of it, simply merge
together all the seperate modules. This all sounds like a lot of
work - in fact, it saves time: I bet that, at the moment, you
type all your code in at one go. You then assemble and try to
run it. It crashes. You restore the code and fiddle about with

it trying to find the error, using breakpoints and a monitor, or
something. When you finally find the error you sort it and
re-assemble the whole program...

Ugh. Instead, using the modular approach, thare is less code to
search for errors, and (more noticeably) there is less code to
re-assemble every time you make a change.

Of course, you can build up a library of "standard" routines
(like sprite routines, for example) and simply merge these into
programs, fully tested already.