Simulation (Stage 3.2) -- Standard Coding Practices

It is useful to establish to establish some standard coding practices to avoid simple errors. That means we can avoid wasting time debugging these simple errors and concentrate on the more "creative" part of our code.

We have already adopted a number of these practices implicitly

Other standard practices that are useful to adopt are

Since I find all these practices cut down on the number of errors that I make, I attempt to follow them. When I don't succeed, my error rate goes up considerably.


Explicit memory size description for instructions

When we allocated space for constants we used the assembler directive DC.W to allocate a 16-bit memory location. There are a number of other DC directives available

Except for the DC command, all the other directives specify the memory word length within the instruction. HVZ used the DC.W syntax to indicate that they wanted 16-bit space allocated for the variables.

Each of the 68K instructions has a similar format to the DC instruction. For example, the MOVE instruction can be used as follows

My coding scheme is always to explicitly specify the LENGTH of the data being used in the instruction. Thus the HVZ code

	MOVE A, D0
	ADD B, D0
	MOVE D0, C

would become

	MOVE.W A, D0
	ADD.W B, D0
	MOVE.W D0, C

By getting into the habit of thinking about the 16-bit data size associated with the MOVE.W or ADD.W instructions (rather than letting the assembler do the job by translating the MOVE and ADD instructions) I experience less problems when the extension becomes important. For example, when accessing the 32-bit COFFEEPOT device registers during Laboratory 2 it is necessary to use the .L extension or else the device will not operate

Return to the start of this page.


Explicit address modes

There are many 68K addressing modes discussed in HVZ Chapter 2. The most frequently used addressing modes are the following

Addressing Mode Example Meaning
Immediate MOVE.W #6, D0 D0 = 6
Absolute long MOVE.W 6, D0 D0 <- [6]
Register MOVE.W D1, D0 D0 <- [D1]
Register indirect MOVE.W (A0), D0 D0 <- [[A0]]

The most frequently confused instructions are the Immediate and Absolute long instructions. For example, consider the following code segment.

	section const		; Assume that the start of "const" is 0x200
FIRST	DC.W 0x400
	section code
	MOVE.W #FIRST, D0
	MOVE.W FIRST, D1
	MOVE.W #FIRST, FIRST

What values are in registers D0, D1 and memory location FIRST after executing the code segment?

The IMMEDIATE instruction (MOVE.W #FIRST, D0) means move the value of the FIRST label into register D0. Since the label FIRST is at the start of "section const", its value is 0x200 so that D0 will contain that value after the code segment executes.

The ABSOLUTE LONG instruction (MOVE.W FIRST, D1) means move the value in the memory location labeled FIRST. The instruction indirectly uses the value of the FIRST label as a memory location/address to fetch the actual value used by the instruction. A REGISTER INDIRECT instruction (e.g. MOVE.W (A0), D3) uses the value inside the register A0 in the same "indirect" manner. This register D1 will containing the value 0x400 after the code segment executes.

The IMMEDIATE/ABSOLUTE LONG mixed mode instruction (MOVE.W #FIRST, FIRST) places the value of the label FIRST into the memory location specified by the label FIRST. This is another example of the "indirect" use of the label FIRST during the storing operation associated with the MOVE.W instruction. Thus memory location FIRST will contain the value 0x400, but the label FIRST retains its constant 0x200 value. In terms of the HVZ syntax

I have found that I (and my students) frequently drop the hash mark (#) from the IMMEDIATE instruction turning into an ABSOLUTE LONG instruction. This error is very difficult to spot since the syntax for both instructions is very similar and frequently code consists mainly of these two types of instructions.

My own coding practice to reduce (not remove) the difficulty of distinguishing these two instructions is to use the alternative indirect version of the ABSOLUTE LONG instruction

This makes the difference between IMMEDIATE and ABSOLUTE instruction syntax greater. Combine this approach with a code review looking for (and correcting) instruction syntax of the form MOVE.W FIRST, D0 to be either

most of the typos associated with these instructions can be removed from the code, avoiding wasting time trying to spot them later during the test and debug phase. Unfortunately, this is a WILL POWER option on behalf of the programmer rather than an option that can be activated on the assembler.

With this approach the code segment above becomes

	section const		; Assume that the start of "const" is 0x200
FIRST	DC.W 0x400
	section code
	MOVE.W #FIRST, D0
	MOVE.W (FIRST), D1
	MOVE.W #FIRST, (FIRST)

You can see this approach applied in the source file t1final.s.

This convention matches up with the syntax used for indirect use of address registers

	MOVE.L A0, D0		; D0 <- [A0]
				; Move the value in register A0
	MOVE.L (A0), D0		; D0 <- [[A0]]
				; Move the value in the memory location
				; pointed to by register A0

Despite the number of errors I avoid using this coding convention, it is the one that I find the most difficult to keep to. This is because I have not fully adopted a "code review" as part of my HIW process.

Return to the start of this page.


Specifying label definitions using the colon (:)

Consider the following code segment

	section const
AVARIABLE 	DC.W 0x400	; Label definition
	section code
	MOVE.W (AVARIABLE), D0	; Label use

The meaning of AVARIABLE in the first line is associated with the definition of a label. In the second line we are using rather than defining AVARIABLE. I have adopted a coding convention that brings out these differences. This coding convention makes use of a colon (:) during label definitions.

	section const
AVARIABLE:	DC.W 0x400	; Label definition
	section code
	MOVE.W (AVARIABLE), D0	; Label use

Some assemblers require the presence of the colon, others insist you don't use one. The SDS assembler does not care what approach you use in your source code.



Last modified: July 12, 1996 06:28 AM by M. Smith.
Copyright -- M. R. Smith