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
Additional white space between ideas in a file section const FIRST DC.W 0x200 ; Define and initialize a constant section code mycode MOVE FIRST, D0 ; D0 = [FIRST]
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.
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.
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.
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