PPC-Notes October 1996 Sam Jordan *--------------------------------------* 1. Introduction --------------- The last 11 years the AMIGA worked with the 680x0-processors. In the future a new processor family will be implemented: the PowerPC from Motorola / IBM. I would like to discuss the features of the new CPU's and I want to show what the assembler programmers will expect. 2. Assembler and PowerPC ------------------------ The PowerPC has a different instruction set than the 68K family. So new development tools are needed to create assembler programs. At the end of May 1996 I started with the development of an assembler development environment. It will be possible to translate PPC-sources as well as 68K-sources due to the in-built 68K to PPC-Crossassembler. It will be even possible to translate only parts of an existing 68K- Source. I decided to write this text because I got very much informations about PowerPC due to the work at my project. Now I want to share my knowledge and I want to inform every assembler programmer about the news and problems coming with PowerPC. For example, I wrote down some rules that everyone, who wants to port his software to PPC, should follow. 3. The PowerPC-processor ------------------------ The PowerPC-processor is a RISC-CPU. RISC means 'reduced instruction set computer'. Meanwhile, the word 'RISC' has lost its original meaning, for example the PPC has a very large instruction set. The most important features of RISC-processors are: - All commands have the same length (usually 4 bytes) - 'Load/store-architecture'. That means that the commands are strictly separated into commands that access memory and commands that perform calculations. For example, it is not possible to perform mathe- matical operations directly with memory contents. Now I want to show the most important features of current PowerPC- processors, especially those that are important for assembler programmers: - There are each 32 general purpose registers for the integer unit, respectively the FPU. There is no separation into data/address registers anymore. - Every command has only one addressing mode. This is probably one of the biggest differences to the 680x0-processors. Basically, mathematical operations only work with registers, while load/store commands know additionally the addressing modes (Rn) and d16(Rn). - There are many additional mnemonics that don't correspond to a processor command but are translated by the assembler into an equivalent command. These mnemonics are thought as a help for assembler programmers and they simplify very much the change to PowerPC programming. Many 68K commands can be used almost in the same way. By the way, my assembler will support EVERY extended mnemonic. There are a lot: for example there exist over 200 (!) branch- mnemonics. - There are no commands that handle 32-bit-immediate operands anymore (due to the command-size limitation to 4 bytes). A 32-bit-value has to be loaded into a register using two separate commands. - Most of the commands have three operands. That means, that the result of an operation between two registers is stored in a third register. Example: add r1,r2,r3 The result of the addition of the registers r2 and r3 is stored into the register r1. r2 and r3 are unaffected. - The destination register is now the leftmost operand. So you have to write the operands of a PPC-'move' command just reversely. By the way, the PPC actually doesn't know a 'move'-command anymore. But there is an extended mnemonic for that purpose ('mr') that is translated into an 'or'-command by the assembler. - Mathematical operations are only possible with longwords. Commands like move.b / add.w / lsr.b don't exist anymore. Of course it will be possible to calculate with bytes and words furthermore, but it must be programmed in a different way. - Many commands have two forms. The programmer can decide whether a command should affect the condition codes or not. Therefore it is possible to compare two values and evaluate the result after many other commands, as long as the other commands don't affect the condition codes, too. - There are now 8 different condition fields of 4 bit each, situated into the codition register. It's possible to do 8 comparisons and nevertheless you have access to all results. - Some terms have changed: 68K: PowerPC: ---- -------- Word Halfword Longword Word Quadword Doubleword - The bitnumbering has changed, too. The MSB (most significant bit) has the number 0. Of course many assembler programmers will hesitate to change to the PPC and to learn a new language. Additionally RISC-CPU's have the image to be very difficult to program in assembly language. Actually I know the PPC-commands rather good and I have to say that the PPC is very sympatical to me. The commands have logical names and the big instruction set allows creative programming as well. 4. Porting 68K-software ----------------------- As I said already, my assembler will be able to translate 68K-Sources to PPC-Code. But this will only work if the assembler programmers follow certain rules. Sources that use plenty of doubtful programming tricks and dirty contructs won't probably have a chance. In future, assembler programs will be used more and more as a supplement to highlevel languages. So it's absolutely necessary to program cleanly, so that the communication between highlevel languages and assembler will work. Below I wrote down some rules and tips that everyone, who wants to port his software to PPC, should follow. Primary rule: The cleaner the programming the greater the chance to have no problems. The time of hackers is definitively over!!! - use parenthesis with complex mathematical terms! Due that almost every current 68K-assembler follows other rules I can't guarantee that my assembler will translate those expressions correctly if there are too few parenthesis. - self modifying code has definitively no more chance! Additionally no constructs must be used that rely to the code size. Commands like bra *+24 won't work. JMP-tables aren't allowed, too: lea table,a0 jmp 0(a0,d0.w) table jmp lab1 jmp lab2 ... - Always call subroutines in a proper way! The PPC doesn't know subroutines in the usual sense, that means there are no more commands that save the return address onto the stack and restore it (bsr/rts). I discuss here some variants of subroutine calls: - 'Shortcut returns' will probably cause major problems, I mean the manipulation of the stackpointer to jump back several levels. Additionally the 'rtd' command should be used with caution. - pea rts This kind of a normal jump will probably be translated if these commands are close enough to eachother. But there is no guarantee for that and I urgently ask you NOT to use it! - If a pair of 'bsr/rts' is replaced by a 'bra' there should be NO problems (same for 'jsr/jmp'). But I can't guarantee this yet. - Library calls should be made with the appropriate macros (CALLSYS, CALLEXEC,...). It's possible that libraries will be called totally differently in future than today. I can't guarantee that my assembler will recognize EVERY standard 68K-library call. - 68K commands with longword extension (.l) will be translated into faster code than those with byte/word extension. This is because the PPC doesn't know byte/word commands and the emulation of the 68K behaviour is rather complicated. 5. Conclusion ------------- Developing my own assembler, I want to take care of the wishes and desires of the assembler programmers. So I prepared a small inquiry in form of a textfile 'Inquiry.txt' and I hope that many people will fill out this file and send it to me per eMail. If you have any questions to PowerPC or to my assembler-project feel free to contact me and I'll answer your questions per eMail. I'll answer as quickly as possible, except when we have school holiday (currently I don't have internet access at home (yet)). My address: Sam Jordan Dammstrasse D 7302 CH-Landquart eMail: jordsamo@htlchur.ch Happy programming!