Pic32 Assembler

Ressourcen

Interessiert einen die Assemblerprogrammierung für den PIC32 sind erst mal folgende Ressourcen von großem Wert:

• MPLAB® XC32 C/C++ Compiler User’s Guide.
• MPLAB® Assembler, Linker and Utilities for PIC32 MCUs User’s Guide
• MIPS32® Instruction Set Quick Reference (cheat sheet)
• MIPS32™ Architecture For Programmers Volume II: The MIPS32™ Instruction Set (ausführliche Referenz)

Folgendes scheint auf den ersten Blick noch interessant zu sein. Es dürfte leichter lesbar als die Befehlssatzreferenz sein. Aber hier und da gibt es auch noch einige Lücken:

• MIPS Assembly Wikibook

Bisher Gelerntes

To assemble or not to assemble

Für einige Dinge ist es gar nicht notwendig, sich die Hände dreckig zu machen. Beispielsweise bietet der Header <xc.h> so einiges an Makros für schon fertige Inline-Assembler Schnipsel oder __builtin-Funktionen (Intrinsics). Auch sollte man sich mal schlau machen, was Microchip so an Bibliotheken schon anbietet. Da gibt es zum Beispiel die DSP-Bibliothek, die praktische Funktionen für die digitale Signalverarbeitung anbietet. Es steht zwar nicht direkt dabei, aber ich würde mal davon ausgehen, dass die Funktionen handoptimiert wurden und, wo sinnvoll, Gebrauch von den madd/msub-Befehlen (multiply-accumulate mit einem 64-Bit Akkumulator) machen, die der MIPS32-Befehlssatz bietet. So ein 64-Bit Akkumulator ist echt super, wenn man auf Fließkommazahlen verzichten und dafür Festkommazahlen einsetzen will.

Andererseits entsteht mit der Nutzung dieser Bibliotheken natürlich auch eine PIC32-Abhängigkeit wohingegen selbst geschriebener MIPS32 Code relativ universellt ist; denn den versteht ja nicht nur der PIC32. Und ein bisschen Hände schmutzig machen kann ja auch Spaß machen. :D

Register Konventionen

Die 32 Register können seitens der CPU eigentlich nahezu beliebig verwendet werden. Das kann man schon daran erkennen, dass sie $0, $1, ..., $31 heißen. Es gibt aber ein paar Konventionen, was die Verwendung dieser Register angeht, an die man sich spätestens dann halten sollte, falls man mit C/C++ Code interagieren will. Die von der XC32-Toolchain verwendete Konvention heißt "O32". Sie legt alternative Registernamen fest und wie diese Register bzgl Funktionsparameterübergabe, Wertrückgabe, Stackbenutzung etc verwendet werden. Die oben verlinkte Befehlskurzreferenz beschreibt dies auch kurz. Der entsprechende Teil des Wikibuchs ist hier. Hier und da ist sicherlich noch mehr Information dazu zu finden. Wichtig ist: Die Register $at, $k0, $k1 fasst man am Besten gar nicht an. $at ist für ein temporäres, für den Assembler reserviertes Register, mit dem er Pseudo-Instruktionen übersetzen kann, die ein solches zusätzliches Register benötigen. $k0 und $k1 sind Register, die für den Kernel reserviert sind. Also, wenn man User-Land Code schreibt, hat man mit denen nix anzustellen. Die Register $s0 bis $s7 sind die, die man selbst zu sichern hat, weil die aufrufende Funktion Änderungen an diesen Registern nicht erwartet. Die Register $t0 bis $t9 sind die temporären Register, die eine aufgerufene Funktion einfach verändern darf. Die Register $a0, $a1, $a2 und $a3 speichern biszu vier Funktionsparameter. Der Rest wird dann über den Stack erledigt. Den Stack manipuliert man über den "stack pointer" $sp, wobei der Stack von "oben nach unten wächst". Das Register $ra speichert die Rücksprungadresse. Wenn man selbst Funktionen aufruft (oft per jal-Befehl), speichert man typischerweise die alte Rücksprungadresse sowie die alten $s?-Werte vom Aufrufer auf dem Stack, damit man sich selbst in $s? etwas merken kann.

Dateiendung, Assemblieren mit Präprozessor

Der oben verlinkten Dokumentation kann man entnehmen, dass man seine Assembler-Dateien eine Endung mit einem großen S spendieren solle. Das erlaubt, im Gegensatz zu Assembler-Dateien mit einem kleinen s als Endung die Verwendung des C-Präprozessors. Die von der Toolchain mitgelieferten Header-Dateien sind sogar teilweise dafür gedacht, in solche Assembler-Dateien eingefügt zu werden. So darf man z.B. den <xc.h>-Header einbinden. Dieser Header enthält unter anderem Makro-Definitionen, die es erlauben, die alternativen Registernamen ohne das Dollarzeichen zu verwenden oder eben auch die SFRs (special function registers) zu nutzen. Hier mal ein Beispiel, wie so etwas aussehen könnte:

	.text            # Text-Segment
	.globl dot32x16  # Symbol exportieren

# Funktion
#   int64_t dot32x16(int n, const int32_t x[], const int16_t y[]);
# mit Eingabe
#   a0 = n, die Dimension
#   a1 = Adresse des ersten Elements vom "x-Vektor"
#   a2 = Adresse des ersten Elements vom "y-Vektor"
# und erwarteter Ausgabe
#   v0 = niederwertiges Wort des Rueckgabewertes
#   v1 = hoeherwertiges Wort des Rueckgabewertes
# nach O32 mit Little-Endian-Konvention bzgl Aufteilung von
# 64-Bit-Werten auf zwei 32-Bit-Register.
	.ent dot32x16
dot32x16:
	mtlo  $zero              # LO = 0;
	mthi  $zero              # HI = 0;
	beqz  $a0, .L_loopEnd    # if (a0==0) goto .L_loopEnd;
.L_loopStart:
	lh    $t2, 0($a2)        # t2 = *(int16_t*)(a2+0);
	lw    $t1, 0($a1)        # t1 = *(int32_t*)(a1+0);
	addiu $a0, $a0, -1       # a0--;
	addiu $a2, $a2,  2       # a2+=2;
	addiu $a1, $a1,  4       # a1+=4;
	madd  $t1, $t2           # HI::LO += t1*t2;
	bnez  $a0, .L_loopStart  # if (a0!=0) goto .L_loopStart;
.L_loopEnd:
	mflo  $v0                # v0 = LO;
	mfhi  $v1                # v1 = HI;
	jr    $ra                # goto ra (Ruecksprungadresse);
	.end dot32x16
 

(Diesen Code habe ich bisher nicht getestet, nur durch den Assembler gejagt. Er mag also falsch sein.)

Allerdings funktioniert die Verwendung der alternativen Namen auch ohne das Einbinden der Headerdatei. Nur dann muss den Namen das Dollarzeichen vorangestellt werden, also $v0 statt v0 beispielsweise.

Lokale Sprungmarken, die nicht als Symbole in der Objektdatei landen, kann man mit dem .L-Präfix erzeugen.

Das geübte Auge mag hier entdeckt haben, dass ich (sg) mich bei dem vorangegangenen Beispiel gar nicht um die Branch Delay Slots gekümmert habe, die das Nachvollziehen von MIPS32-Assembler etwas erschweren. So, wie ich das aktuell verstehe, ist das ein Feature des GNU Assemblers, der, wenn man ihm nicht explizit .set noreorder sagt, die Jumps automatisch gegebenenfalls vorverlegt oder ein Nop dahinter einfügt. Das, was der Assembler hier aus diesem Code macht, wird weiter unten gezeigt.

Kompilieren tut man das Ganze dann einfach mit dem C-Driver, also xc32-gcc und nicht xc32-as. Letzterer wird wahrscheinlich automatisch vom GCC aufgerufen, nachdem der Präprozessor seinen Dienst getan hat. Wenn man den Präprozessor nicht braucht, sollte es aber auch mit dem xc32-as direkt gehen. Allerdings sind die Optionen des xc32-as ganz anders. Ein "-c" zum Generieren der Objektdatei versteht das Ding nicht. Man muss ihm manuell sagen, wie die Objektdatei, die er erzeugen kann, heißen soll.

sebi@laptop ~/Documents/ccpp/pic32tests/audio-pwm-asmtest
$ xc32-gcc -c dot32x16.S

sebi@laptop ~/Documents/ccpp/pic32tests/audio-pwm-asmtest
$ xc32-objdump -d dot32x16.o

dot32x16.o:     file format elf32-tradlittlemips


Disassembly of section .text:

00000000 <dot32x16>:
   0:   00000013        mtlo    zero
   4:   10800008        beqz    a0,28 <dot32x16+0x28>
   8:   00000011        mthi    zero
   c:   84ca0000        lh      t2,0(a2)
  10:   8ca90000        lw      t1,0(a1)
  14:   2484ffff        addiu   a0,a0,-1
  18:   24c60002        addiu   a2,a2,2
  1c:   24a50004        addiu   a1,a1,4
  20:   1480fffa        bnez    a0,c <dot32x16+0xc>
  24:   712a0000        madd    t1,t2
  28:   00001012        mflo    v0
  2c:   03e00008        jr      ra
  30:   00001810        mfhi    v1
 

Man kann hier auch schön sehen, wie der Assembler die Jumps alle vorgezogen hat. In diesem Fall ist er sogar ohne weitere Nops ausgekommen. Das kommt auch ein bisschen darauf an, wie man seine Befehle selbst sortiert. Man sollte vielleicht beim Schreiben darauf achten, dass der Compiler einen Jump auch vorziehen kann. Wenn es ein bedinger Sprung ist, und die Bedingung direkt von der vorhergehenden Anweisung beeinflusst wird, wird der Assembler den Sprung natürlich nicht vorziehen sondern stattdessen ein Nop einfügen. Die Umordnungsregeln scheinen also recht einfach zu sein. Ich (sg) denke, man sollte dieses Feature auch ausnutzen, weil der aufgeschriebene Code dadurch leichter nachvollziehbar ist. Um Nops zu sparen muss man lediglich dafür sorgen, dass die Sprungbedingung nicht direkt vorher beeinflusst wird.

Alternativ kümmert man sich selbst um den Branch-Delay-Slot und teilt dies dem Assembler über ein .set noreorder mit.

Vergleich zum GCC

Wenn man den Code

#include <stdint.h>

int64_t dot32x16(int n, const int32_t x[], const int16_t y[])
{
	int64_t acc = 0;
	while (n>0) {
		--n;
		acc += (int64_t)x[0] * y[0];
		++x;
		++y;
	}
	return acc;
}
 

mit -Os durch den GCC jagt, kommt dann so etwas raus (von Hand kommentiert, umsortiert und ggf mit Nops erweitert, damit man nicht über die Branch-Delay-Slots stolpert):

00000000 <dot32x16>:                                  Pseudo-C
-------------------------------------------------------------------------------------
   0:	00004021 	move	t0,zero               t0 = 0;
   8:	00004821 	move	t1,zero               t1 = 0;

t0 und t1 scheint unserer "Akkumulator" zu sein

   4:	08000016 	j       58 <dot32x16+0x58>    goto 58;
                        nop
   c:	84c30000 	lh	v1,0(a2)              v1 = *(uint16_t*)(a2+0);

v0 und v1 speichern x[k] und y[k] für k=0...n-1

  10:	2484ffff 	addiu	a0,a0,-1              a0--;
  14:	00023fc3 	sra	a3,v0,0x1f            a3 = s(v0) >> 31;
  18:	00e30018 	mult	a3,v1                 Hi::Lo = signed(a3)*signed(v1);
  1c:	000357c3 	sra	t2,v1,0x1f            t2 = s(v1) >> 31;
  20:	24a50004 	addiu	a1,a1,4               a1 += 4;
  24:	24c60002 	addiu	a2,a2,2               s2 += 2;
  28:	71420000 	madd	t2,v0                 Hi::Lo += s(t2)*s(v0);
  2c:	00003812 	mflo	a3                    a3 = Lo;
  30:	00620019 	multu	v1,v0                 Hi::Lo = u(v1)*u(v0);
  34:	00001012 	mflo	v0                    v0 = Lo;
  38:	00001810 	mfhi	v1                    v1 = Hi;
  3c:	00e31821 	addu	v1,a3,v1              v1 = a3+v1;
  40:	01023821 	addu	a3,t0,v0              a3 = t0+v0;
  44:	00e8502b 	sltu	t2,a3,t0              t2 = u(a3)<u(t0) ? 1 : 0;
  48:	01234021 	addu	t0,t1,v1              t0 = t1+v1;
  4c:	01481021 	addu	v0,t2,t0              v0 = t2+t0;
  50:	00404821 	move	t1,v0                 t1 = v0;
  54:	00e04021 	move	t0,a3                 t0 = a3;

  58:	5c80ffec 	bgtzl	a0,c <dot32x16+0xc>   if (a0>0) {
  5c:	8ca20000 	lw	v0,0(a1)                v0 = *(int32_t*)(a1+0);
  /* lw wird nur "beim Sprung" ausgeführt! */           goto C; }

  60:	01001021 	move	v0,t0                 v0 = t0;
  68:	01201821 	move	v1,t1                 v1 = t1;
  64:	03e00008 	jr	ra                    goto ra;
                        nop
 

So richtig toll ist das jetzt nicht, was der GCC da generiert hat. Es ist mehr als doppelt so lang (trotz des -Os Schalters) und wahrscheinlich auch einiges langsamer als der von Hand geschriebene Code von oben.

Simulation

Mit dem Java-Programm MARS kann man kleine Assemblerprogramme in einer sehr einfachen, virtuellen Maschine laufen lassen. Schrittweise Ausführung vor- und rückwärts sind möglich. Man kann sich all die Registerinhalte und den Speicher dabei anschauen. Von Branch-Delay-Slots weiß das Ding aber scheinbar nichts. Der Editor ist gar nicht übel. Er zeigt einem ganz nette Hilfen an. Mit MARS habe ich die obige Funktion getestet. MARS versteht nicht alle Befehle, seh (sign-extend-half) kannte er z.B. leider nicht.

Branch-Delay-Instruction wird nicht immer ausgeführt!

Ich habe gerade gelernt, dass die Anweisung hinter einem Sprung, die Branch-Delay-Instruction, nicht immer ausgeführt wird, wie ich zunächst dachte. Es gibt einige bedingte Sprungbefehle, die gegebenenfalls die im Branch-Delay-Slot stehende Anweisung rausschmeißen. Das Beispiel, was mir vorhin untergekommen ist, sieht so aus

 5c80ffec    bgtzl   a0, irgendwohin
 8ca20000    lw      v0, 0(a1)
 

Das ist ein Branch-on-Greater-Than-Zero-Likely. Die darauf folgende Anweisung liegt im "Branch-Delay-Slot". Diese wird aber nicht immer ausgeführt. Sie wird nur bei einem Sprung ausgeführt. Falls die Sprungbedingung nicht zutrifft, wird sie aus dem "Branch-Delay-Slot" rausgeschmissen und quasi ignoriert.

Komisch

Was ich komisch finde, ist, dass der xc32-gcc aus

 int mul42(int x)
 {
     return x*42;
 }
 

mit -O2 so etwas macht:

 00000000 <mul42>:

   /* x = x*6 ... */
    0:   00041040        sll     v0,a0,0x1   /* v = x << 1; */
    4:   000420c0        sll     a0,a0,0x3   /* x <<= 3;    */
    8:   00822023        subu    a0,a0,v0    /* x -= v;     */

   /* v = x*7 ... */
    c:   000410c0        sll     v0,a0,0x3   /* v = x << 3; */
   14:   00441023        subu    v0,v0,a0    /* v -= x;     */

   /* return v;   */
   10:   03e00008        jr      ra
                         nop
 

Sind drei Shifts und zwei Subtraktionen wirklich "optimaler" als eine einfache Multiplikation? Eigentlich nicht! Denn laut Doku kann die CPU eine solche Multiplikation in einem Taktzyklus erledigen. Was übersehe ich da nur? Weiß der GCC auch, wieviele Taktzyklen die CPU so für diverse Operationen benötigt? Gibt es da noch irgend etwas zur Pipeline, was ich hier nicht berücksichtige? Ist der Austausch zwischen Excecution Unit und der MDU (Multiply Divide Unit) irgendwie besonders teuer? Ich raff das nicht. Bitte erklärt es mir ...