Assembly (Stage 4) -- Further interpretation of the listing file

In addition to the error messages in the file e1v1.lst, there are a series of hexadecimal numbers associated with each line of code. Normally, these values can be ignored, but they provide some useful information to us at this point in Laboratory 1.

000000 027F          A  DC.W 639
000002 FF29          B  DC.W -215

000004 303900000000	MOVE A, D0
00000A D07900000002	ADD B, D0
000010 33C000202200	MOVE D0, C

Understanding the hex code patterns in the listing

Note that the numbers in the listing are given in hexadecimal rather than decimal. Although it is obvious that the value 00000A is a hexadecimal number, it is not clear whether the value 000010 (or more simply 10) is decimal or hexadecimal. We shall therefore adopt the convention of placing a symbol in front of hexadecimal numbers to signify their "hexadecimalness". There are a number of possible approaches.

It is a "our" choice which approach to use since the SDS 68K assembler will accept both notations. However, since SDS PowerPC assembler only accepts the "C" version, I will use the 0x convention always.

The hex code patterns for each instruction can be seen in the listing. This is not normally useful information and under most circumstances you would say "NEAT" and move on to more important matters. However, at this point in our knowledge of what the SDS toolkit does, these lines do contain some interesting information.

Consider the line MOVE D0, C. We have to interpret the hex code pattern 0x33C000202200 as two hex patterns

The hexadecimal numbers for lines MOVE A, D0 and ADD B, D0 follow a similar format, the instruction information (4 hex characters) followed by a memory location specification (8 hex characters). However, note the other memory locations specified.

At this point in time the assembler has not put these labels where we want them (at memory locations 0x201200). It has simply placed them at the start of memory. This is partly because the ORG directive has not been recognized. However, you would have seen the same hex values in the listing even if the ORG directive had been recognized. This is because the SDS assembler generates "relocatable" code and requires a linking stage and a memory map specification file to place data and code in the correct memory locations. These extra stages are the same for all executable file generation and are easily automated.

We now need to move on to solve the problem with the ORG directive.



Last modified: July 02, 1996 06:41 PM by M. Smith.
Copyright -- M. R. Smith