What Speed Costs You

Translating before a program runs can remove work from its execution. It does not make every program faster or make assembly the right choice for every game. The result depends on the program, its implementation and the machine.

We can compare three responsibilities before choosing how to build something.

Keep a route back to the source

An interpreter can often report a problem at the line it is executing. An assembler can report problems before execution too, such as an instruction it does not recognise or a name that has not been defined.

Neither can reliably recognise that a valid instruction means the wrong thing. If we meant to add two but wrote an instruction that subtracts two, the program may run without a diagnostic and produce the wrong answer.

Machine code alone does not usually contain our source names. We can keep a listing or debugging information alongside it to connect addresses back to labels and source lines. A debugger can then help us stop, inspect registers and memory, and step through the program. The information must match the build we are running; an old listing can send us to the wrong place.

The method from Structure still helps: compare what happened with what we expected, then narrow down the difference. Messages, trace tables and debugger observations are evidence we can use together.

Make more details explicit

FOR i = 1 TO 1000 describes repetition in one line. In our tiny teaching machine, we arrange a loop from smaller operations: change a counter, compare it with a limit and jump back when more work remains.

Assembly exposes such details directly. Real processors have different instructions, and assemblers can also provide labels and macros to reduce repetition. Source-line count is not a reliable measure of either program size or speed. We need to examine the generated instructions and the path that runs.

Separate the idea from its machine interface

Instruction encodings belong to a processor’s instruction set. Compatible processors can share instructions, but two computers using that instruction set may still have different screen memory, sound hardware and operating-system services. A complete game depends on those interfaces as well as its CPU.

An interpreter can help us reuse source, but its language dialect and available facilities still matter. A BASIC program that writes directly to one machine’s sound registers will not gain the correct registers for another machine merely because both have BASIC.

Suppose we keep a puzzle board as a grid of numbers. Its rule for a legal move may transfer unchanged as an idea. We may need different code to read a key or draw the changed cells. Naming those jobs separately helps us see what can be reused and what needs adapting; it does not remove the target’s constraints.

Try the distinction

Imagine moving that puzzle to a machine with different graphics and sound. Which parts would we inspect first: the rule for pushing a crate, the routine that draws it, or both?

Now suppose the picture is right but a crate can pass through a wall. Which observation would help: comparing the stored board before and after that push, or changing the crate artwork? Explain what each would tell us. The earlier diagnosis lesson shows how to choose evidence that separates two possible causes.

What we’ve learnt

• Translation tools can diagnose some mistakes; valid code can still express the wrong rule.
• Matching listings and debugging information help connect execution to source.
• More explicit control brings responsibilities, not an automatic speed guarantee.
• Algorithms, source code and complete programs have different portability limits.

What’s next

In Unit 5 we put execution on a clock. We will need to say what we are measuring before deciding whether one version does less work than another.