[Coco] Optimizing 6809 Assembly Code: Part 2 – Speedup Storing Data – Unrolling Loops

[Joel Rees]

A few comments and words of caution.

I think everyone is aware of the concept that optimization for time is
often at the expense of space and vice versa. (An extreme example is loop
unrolling).

There are other factors that play into the questions of optimization as
well.

Consider the method of passing a string pointer after the call instead of
on the stack to optimize for space. This is useful when the pointer is a
constant known at assemble-time. This is true of basically any type of
constant -- numbers, records/structure, etc.

Consider what happens when a string pointer is not known until a program
executes. Some process (usually interpretation) collects a value in D. But
your print string routine expects the value after the call instruction in
the instruction stream. What then?

Now, say your print string is interrupted. And the interrupting program
also needs to print a string. What happens?

This subtle bug is also seen in code that contains recursive calls to a
function.

Also, what happens when you burn the code into ROM or write protect it to
prevent stack collisions and crashes from taking over a system? (I'd have
asked this question first, but these are separate kinds of bugs.)

Converting the fig-Forth model interpreter from the 6800 model I had to
6809 taught me a lot of this kond of thing, but I'd have learned a bit more
converting the 6502 model, instead. And Forth itself makes some assumptions
that are not valid in compiled code, or when using careful memory
management to protect the system from certain kinds of attacks.

The SWI instruction is actually not very useful, BTW, unless you have
memory management that goes a bit beyond what the Coco had. It would
generally be faster, more flexible, and use less code to use a BSR or JSR
that includes a pointer into a table of system routines as well as the
value being passed in. (Actually, I should call it a selector, because it
may not actually be implemented as a jump table.) That's effectively what
the SWI is, except for one thing.

Calls into system code often need to be accompanied by a switch between
user mode and system mode. If we have strong memory management to protect
the system from stack crashes and similar errors/attacks, we need some way
to distinguish between a simple call and a call into the system. The fact
that a SWI puts interrupt response signals on the control bus provides a
way of automatically performing the switch between user and system mode, if
the memory management hardware is built to recognize the states.

Unfortunately, the Coco MMU didn't have all of the hardware necessary.

--
Joel Rees

http://reiisi.blogspot.com