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!