PowerPC coding (Stage 4) -- Using other knowledge to correct the PowerPC code syntax |
The next step in getting the PowerPC assembly language syntax correct is to use other knowledge or experience we have gained.
The first set of knowledge, associated with the processor architecture specifications, enables us to change to the correct PowerPC register names.
Conventions become important if you want to speed up your code and link to assembly code generated by a "C" compiler. This is one of the long range goals of the "Companion".
A major convention is the designation of the use of registers during subroutines. You shouldn't just arbitarily change values in a register as registers are a "scarce" resource in a processor. You change a register value inside a subroutine and the previous subroutine that was counting on that register value being present, on return from the current subroutine, will no longer work. This means that registers must be saved on entering a subroutine and recovered on leaving.
However, saving and recovering registers requires operations to slow external memory, slow compared to register-register operations. Therefore it is a convention to designate certain registers of the processor as "must-save" registers if they are to be used during a subroutine. Other registers are designated as scratch, temporary, or volatile registers that do not need to be saved on entry to a subroutine.
The convention that I follow for register usage is one that is standard with many "C" compilers and available libraries, including those provided by SDS.
There are a whole series of other register conventions that are used to speed code and code development and allow re-use of subroutines. Different conventions provide different advantages in terms of the amount of memory used, size of memory stack necessary and program speed.
CISC processor assembly language directives often vary from one manufacturer's assembler to another. Not only is there wide variation between directives between different processors (such as 68K and X86 processors) but between assemblers for the same CISC processor, as we have seen with the SDS syntax being different than the original Motorola 68K syntax used in the HVZ book.
However, RISC processors have been on the scene only recently. By the time they arrived, manufacturers were being pushed by customers to be more self-consistent. Since I was familiar with the directives of the Advanced Micro Devices 29K and other RISC processor software, then applying the WIDFI process to Task 1 meant assuming that the PowerPC RISC assembly language directives were similiar to those directives. Note the dot (.) in front of the directives.
68K assembler directive used in Task 1 |
Directives from other RISC processor assemblers (assumed PowerPC assembler directive) |
---|---|
SUM: EQU 0x7220 | SUM: .equ 0x7220 |
section const | .text |
section code | .text |
section data | .data |
section ram | .data |
.EXPORT | .global |
.IMPORT | .extern |
FIRST: DC.W 0x123 | FIRST: .short 0x123 |
Working with the directives brought out an architectural difference between RISC processors that I had not anticipated meeting. The problem lay with translating the DC.W syntax. The other RISC processors I had used were very much 32-bit processors, and their assembly language directives reflected that. There were very few 16-bit instructions/directives on these processors, unlike the PowerPC which is very like the 68K in its capability to perform 16-bit operations. The WIDFI process suggested -- try a construct from the "C" language. Since 16-bit values are "short ints" in that language, try the directive .short.
Information on the operable DIAB DATA assembler directives can be found in the file active.s. The major things of which you should be aware are
Taking the above ideas we get the source file t1v1.s which we can pass through the DIAB das assembler.
# A PowerPC routine for SUM <- [FIRST] + [SECOND]
**************************************************
SUM: .equ 0x7200 # Specify location to store the result .text # section const .global FIRST FIRST: .short 0x123 # FIRST = 0x123 SECOND: .short 0x456 # SECOND = 0x456 .text # section code .global mycode mycode: # MOVEA.L #FIRST, A0 ADDI R3, 0, (FIRST & 0xFFFF) # (On PowerPC move bottom 16 bits, ADDIS R3, R3, (FIRST >> 16) # then top 16 bits of address FIRST) LHZ R4, (R3) # MOVE.W (A0), D0 # MOVEA.L #SECOND, A0 ADDI R3, 0, (SECOND & 0xFFFF) # (On PowerPC move bottom 16 bits, ADDIS R3, R3, (SECOND >> 16) # then top 16 bit of address SECOND) LHZ R5, (R3) # MOVE.W (A0), D1 (Note the change) ADD R4, R4, R5 # ADD.W D1, D0 # MOVEA.L #SUM, A0 ADDI R3, 0, (SUM & 0xFFFF) # (On PowerPC move bottom 16 bits, ADDIS R3, R3, (SUM >> 16) # then top 16 bits of address SUM) STH R4, (R3) # MOVE.W D0, (A0)
As mentioned earlier, it is useful to try things out when using an assembler for the first time. Attempting to understand the problems you unintentionally introduce can stand you in good stead later. If you are interested in working ahead of me you can use the following syntax to assemble from the DOS window's command line
das -l t1v1.s
Alternately configure the SDS PowerPC assembler GUI window.
Warning:- If you had tried using the 68K assembler from the DOS window, you would have got a listing file with embedded error messages. This makes it straight forward to identify error and offending source code line. However if you do the same task with the PowerPC assembler, the errors scream past on the screen and never get into the listing file. This can be a real time-waster when your source code has many lines in it.
The disadvantage of no errors in the listing file would not be such a problem if the PowerPC assember GUI interface had one of the advantages of the 68K assembler GUI interface With the 68K interface, double clicking on the error message in a special window brought up the offending line in the source file. Unfortunately the PowerPC GUI interface does not have that feature.
You'll just have to take the line numbers for the errors down the old fashioned way, using specialized wood and graphite hardware, and match them with the lines in the source file! Watch out for information on my WEB site about fixing that problem with a program that will merge the listing and error files.
![]() |
Last modified: July 22, 1996 12:44 PM by M. Smith Copyright -- M. R. Smith