Getting the PowerPC simulator download to work automatically

This page simply details a WIDFI fight to overcome the limitations with Version 6.5 of the SDS PowerPC simulator demo kit. The result is a workable solution of evaluating code operation on the PowerPC, but not as pleasant to use as the SDS 68K simulator. Many of these problems are associated with the fact that the DIAB DATA PowerPC assembler does not put out sufficient information for the SDS simulator to work with. Note that the DIAB DATA PowerPC compiler does put out the necessary information. Unfortunately, that's no good for us. (However, I am working on being able to use the "C" language directive asm() to overcome this problem)

I am not confident that the problem will be solved in Version 7.X of the demo kit.


Automatically finding the start of our code during simulation

I found that I could download the executable file and see the source file inside the Source window when I set the viewing address to the start of the mycode function as we did during the 68K simulation. However, the PC marker did not step through the code as the program simulates.

Automating the finding of the start of the code looked like a simple extension of the approach for the 68K simulation.

	.global START
START:	etc.

Adding these directives to the start of my source file meant that the simulator automatically set the program counter and the Source window to the correct place in the code.

However, the approach generated unknown line number error messages in the Debug window. I could "click through" these messages and get the window pointing at the start of my code. However, I tried to find an approach to try and solve this "click through" problem before going on to try and debug the code.


A pure WIDFI approach to solve the "START" problem

I modified a startup file crt0.s I found used in conjunction with the SDS tutorial code. I added this part of this file to the start of the my code as this file showed a label __start, something that seemed related to the START symbol I wanted to use. It turned out that either __start or START labels will work.

Looking for a file called crt0.s to get "start-up" information is not a wild shot in the dark, but a reasonable WIDFI approach. On the X86 machines, Borland "C" uses a file of an equivalent name, taking into account the various memory models you can get with those processors. Many other "C" linkers bring in files to initialize the processor configuration before running a program. In fact, one of the problems with the PowerPC GUI linker interface on this PowerPC demo kit is trying to stop the linker from bringing in this file when you don't want it!

These files always contain the code necessary to set up a processor so that it becomes possible to handle "C" code. The code in crt0.s is always executed, which suggests that it also contains the information I need to get "Laboratory 1" running.

It was obviously the correct file to use as it also showed how to establish the stack pointer using the specialized DIAB assembly language directives.


Using the "crt0.s" file information

Adding the crt0.s information at the start of my code stopped the Debug window error messages and placed the program counter directly at the start of my code in the PowerPC simulator memory,

However, it worked only when I had the following directive at the top of the source code!

.file "ppctask.c"

Using the more obvious syntax .file "ppcfinal.s" did not work.

Why is this strange syntax needed? Checking through with the SDS hotline came up with the following facts. Apparently the DIAB DATA assembler does not provide enough information for the SDS simulator to recognize the relationship between the contents of the assembler source code and the actual instructions in memory. Putting in the .file "ppctask.c" apparently tricks the Simulator to recognizing the start of the code.


Working with the PowerPC simulator

Note that since the simulator can't find the correct source file (it believes this is "ppcfinal.c"), you can only display the disassembled code from memory and not the "mixed" mode that was so useful during the 68K simulation.

You'll just have to work with a copy of the listing file at your side. That's a useful approach anyway as you can mark up the listing file with the changes and improvements you need to make. An alternative is to bring up an Editor window, adjusted for size, and place that next to the Source window. If you use this approach then you might want to re-organize the screen so that the Register window is not covered up by the Editor window.

Watch out for a further problem -- the fact that the instructions in the Source window are not exactly the same as those in your source file.

ADDIS and ADDI instructions are becoming LIS and SUBI instructions

The instructions that are decoded by the SDS simulator are interpreted as the PowerPC Simplified Mnemonics. Details of using these mnemonics can be found in Appendix F of the manual Programming Environments put out by Motorola and IBM. A not-yet released version of SDS Version 7.X will have the ability to turn off this simplified instruction mode. Until then, you'll have to work with the Simulator Source window, your source file and lots of WIDFI.


Brief discussion of the Simplified or "extended" PowerPC mnemonics

The disassembled code in the Source window does not "exactly match" the syntax in the source file. For example, the DIAB assembler ADD IMMEDIATE instruction "ADDIZ R3, 0, value" that places a value into a register turns into a very 68K looking simulator LI (LOAD IMMEDIATE) instruction which performs the same task.

I interpret this incompatibility as follows. Instead of the standard "official", powerful but clumsy, PowerPC assembler syntax, many of my reference books make use of the more user-friendly "extended " or "simplified" mnemonics. I paraphrase from Appendix F of the manual Programming Environments put out by Motorola and IBM.

This appendix (on Simplified Mnemonics) is provided in order to simplify the writing and comprehension, of assembler language programs. Included are a set of simplified mnemonics and symbols that define the simple shorthand used for the most frequently used forms of branch conditional, compare, trap, rotate and shift, and certain other instructions.



Last modified: July 22, 1996 01:03 PM by M. Smith
Copyright -- M. R. Smith