PowerPC coding (Stage 3) -- Translate each LOAD/STORE architecture 68K instruction into a PowerPC instruction |
The next step is to translate each of the LOAD/STORE architecture 68K processor instruction into the equivalent PowerPC instruction(s). However, we must take the following processor architectural features into account.
As with 68K syntax, the PowerPC assembler allows many different comment syntax. Because of the limitations of the DIAB DATA PowerPC demo-kit assembler das, I had to test out which comment styles were available -- see file comments.s. Despite what the DIAB manual says, the das assembler only accepts the "hash" mark # to delimit the comments.
We need to know how to handle 32-bit addresses with the PowerPC assembler syntax. This was something automatically handled as part of the 68K processor's complex instructions set. There are advantages to both approaches of handling memory addesses.
One of the HVZ examples (on page 87) mentions using SUMH and SUML as the upper and lower 16-bits of the address of the variable SUM. However, there is no mention on how to get those values from the address associated with the label SUM. We can make an attempt to generate these values using knowledge from equivalent operations in other languages.
In the "C" language we can work out the lower 16 bits of a value by ANDing the value with the mask 0xFFFF (value & 0xFFFF). The AND instruction works the same way as a hardware AND gate, except that the AND instruction works on every bit of the value at the same time.
We can generate a 16-bit value equivalent to the upper 16 bits of a value by SHIFTing DOWN that value 16 places (value >> 16). This moves the top 16-bits into the lower 16 bits of the value, replacing the upper 16-bits with zeros. (We need zero-replacement, rather than sign extension, since addresses are unsigned rather than signed values.)
We shall assume that the DIAB DATA das assembler can handle equivalent to "C" operations (the 68K assembler can). There may be better approaches to generating the two 16-bit portions of the address.
If we take the operations discussed into account, we get the first approximation of the required PowerPC assembly language code. I've made use of some of the HVZ examples to get "the flavour" right.
# A PowerPC routine for SUM <- [FIRST] + [SECOND]
**************************************************
SUM: EQU 0x7200 # Specify location to store the result section const FIRST: DC.W 0x123 # FIRST = 0x123 SECOND: DC.W 0x456 # SECOND = 0x456 section code .EXPORT mycode mycode: # MOVEA.L #FIRST, A0 ADDI A0, 0, (FIRST & 0xFFFF) # (On PowerPC move bottom 16 bits, ADDIS A0, A0, (FIRST >> 16) # then top 16 bits of address FIRST) LHZ D0, (A0) # MOVE.W (A0), D0 # MOVEA.L #SECOND, A0 ADDI A0, 0, (SECOND & 0xFFFF) # (On PowerPC move bottom 16 bits, ADDIS A0, A0, (SECOND >> 16) # then top 16 bit of address SECOND) LHZ D1, (A0) # MOVE.W (A0), D1 (Note the change) ADD D0, D0, D1 # ADD.W D1, D0 # MOVEA.L #SUM, A0 ADDI A0, 0, (SUM & 0xFFFF) # (On PowerPC move bottom 16 bits, ADDIS A0, A0, (SUM >> 16) # then top 16 bits of address SUM) STH D0, (A0) # MOVE.W D0, (A0)
By exposing the internal operation of the PowerPC architecture through these simple instructions, it is possible for an optimizing assembler to rearrange the order of execution of the RISC instructions to create efficient, i.e. fast, programs. It is this optimizing capability that is the reason that many recent CISC processors are implemented as RISC processors internally. For further reading on why the reordering of the order of execution of RISC instructions typically offers such a speed advantage see the book by Mann.
![]() |
Last modified: July 16, 1996 10:38 PM by M. Smith.
Copyright -- M. R. Smith