PowerPC coding -- Explaining the assembler errors generated with the WIDFI process

If you had tried to use the das -l t1v1.s command to assemble the file "t1v1.s", you would have found many errors.


The PowerPC indexed addressing mode syntax

The 68K processor has two styles of memory addressing modes which use an address register that can be translated into a LOAD/STORE format.

In our source code we have assumed that the DIAB DATA assembler would have the same flexibility with the syntax of the "indexed addressing mode. However, it appears to be that the only allowed format with the DIAB DATA PowerPC assembler is

We must have an explicit offset in the PowerPC syntax in order to code its indirect addressing mode correctly, even if that offset is 0.

Actually, this problem is really an example of "Assembler Unfriendly-ness", and not because of something that has been de-activated! We have "made an error" in not specifying the offset according to the "rules" of the assembler. However, the offset is zero, so why should we have to specify it! A zero offset is something the "assembler" should have picked up, fixed and perhaps issued a warning message. The SDS 68K assembler makes many such modifications so why not the DIAB DATA PowerPC assembler. Think how much programming time may get wasted because of this "Assembler Unfriendly-ness". especially for people switching from using 68K to PowerPC processors. The switching is something that DIAB should want to make easy as a good business practice. Their assembler allows many of the other features of the 68K assembler, such as the use (in the full version) of the DC.W instruction.


The meaning of the "unrelocatable expression" error

This is an error I should have anticipated. I did not, as the problem was automatically handled by the other assemblers I have been using, including the SDS 68K assembler.

The assembly language directive (SUM & 0xFFFF) says, as you are assembling the source code

Take the value associated with label SUM and use only the bottom 16 bits of the value

The assembly language directive (FIRST & 0xFFFF) says, as you are assembling the code code

Take the value associated with label FIRST and use only the bottom 16 bits of the value

However, we defined label SUM as a constant, so the assembler "knows" what its value is, and can break that known value up into low and high 16-bits. But, when assembling the source code, the DIAB assembler can just recognize that the value FIRST will become an address in memory. The exact location of this address (its value) will not be known until link time, so the assembler complains.

Other assemblers, such as the SDS 68K assembler, handle this problem a different way. They accept the fact that label FIRST is not yet known. They "make a note" of that fact in the object file and applies the WAIL principle (Worry about it later) to fix things at link time.

We have no idea what location in memory the linker will associate withe label FIRST. We need to force the the DIAB assembler to also apply the WAIL principle to handle taking the lower and upper portions of the address of variable FIRST at link time.

Effectively we are saying that there is one DIAB assembler directive to use

The type of syntax that was needed to correct this was not obvious from my other RISC experiences. I had to search through the example directories and DIAB DATA manuals to find solutions. Then I had to do testing to find out what did and did not work inside the demo kit -- real WIDFI stuff.


Final translation of Task 1 to PowerPC assembly language instructions

We have now completed the WIDFI process in developing the PowerPC source file instructions based on a "LOAD/STORE" architecture version of the 68K code. In the next web pages we move onto more details on assembling, linking and simulating this code.

The resulting source code t1v2.s has the following appearance

# 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@l		# (On PowerPC move bottom 16 bits, 
	ADDIS R3, R3, FIRST@h		#   then top 16 bits of address FIRST)

	LHZ R4, 0(R3)			# MOVE.W (A0), D0

					# MOVEA.L #SECOND, A0
	ADDI R3, 0, SECOND@l		# (On PowerPC move bottom 16 bits, 
	ADDIS R3, R3, SECOND@h		#   then top 16 bit of address SECOND)
 
	LHZ R5, 0(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, 0(R3)			# MOVE.W D0, (A0)

Taking the "upper" and "lower" 16 bits of a variable turned out to be more than just using the directives

You also have to take into account that the PowerPC architecture has many (but not all ) instructions that perform a sign extension of the lower 16 bits. This effect becomes very important when the constants are negative. Since the values (addresses) associated with the labels FIRST, SECOND and SUM are all less than 0x8000, this problem will not affect us in Laboratory 1. However, we will need to consider the problem later.


Internal Errors -- DIAB assembler crashes

I am finding the DIAB assembler, as released in the "starter-kit", not very user friendly and a little too crashable when I make errors. However, I can live with it as

Hopefully some of these problems are fixed in the Version 7.X release.



Last modified: July 22, 1996 12:49 PM
by M. Smith Copyright -- M. R. Smith