2. Aufgabenblatt – Musterlösung

2. Aufgabenblatt – Musterlösung
Technische Informatik II – Sommersemester 2011
Problem 2: Assembler Syntax
Register eines 32-bit Intel-Prozessors:
⟵ 16 bits ⟶
⟵ 8 bits ⟶
⟵ 8 bits ⟶
general purpose registers
EAX Accumulator Register AH AL AX
EBX Base Register BH BL BX
ECX Counter Register CH CL CX
EDX Data Register DH DL DX
ESI
EDI
Source Index
Destination Index
EBP
ESP
Base Pointer
Stack Pointer
⟵ 32 bits ⟶
Weiterführende Informationen zu den Registern und deren Verwendung finden sich in
The Art of Picking Intel Registers (http://www.swansontec.com/sregisters.html)
Hallo-Welt-Programm in C “hello-world.c”
#include "stdio.h"
int main(int argc, int **argv) {
printf("%s\n", "Hello World!");
return 0;
}

“gcc -m32 -S hello-world.c”, Inhalt von “hello-world.s”
.LC0:
.file "hello-world.c"
.section .rodata
.string "Hello World!"
.text
.globl main
.type main, @function
main:
pushl %ebp
movl %esp, %ebp
andl $-16, %esp
subl $16, %esp
movl $.LC0, (%esp)
call puts
movl $0, %eax
leave
ret
.size main, .-main
.ident "GCC: (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.5"
.section .note.GNU-stack,"",@progbits
Vergleichbares hello-world-Programm, handgeschrieben (AT&T-Syntax)
.section .data
hello: .ascii "Hello World!\n"
.section .text
.globl _start
_start:
mov $4, %eax
mov $1, %ebx
mov $hello, %ecx
mov $13, %edx
int $0x80
mov $1, %eax
mov $0, %ebx
int $0x80
# 4 fuer den Syscall 'write'
# File Descriptor
# Speicheradresse des Textes
# Laenge des Textes
# syscall
# Exit-Code setzen
# Funktion 0 (exit) auswählen
# syscall
Vergleichbares hello-world-Programm, handgeschrieben (Intel-Syntax)
.intel_syntax noprefix
.section .data
hello: .ascii "Hello World!\n"
.section .text
.globl _start
_start:
mov eax, 4
mov ebx, 1
mov ecx, offset hello
mov edx, 13
int 0x80
mov eax, 1
mov ebx, 0
int 0x80
# 4 fuer den Syscall 'write'
# File Descriptor
# Speicheradresse des Textes
# Laenge des Textes
# syscall
# Exit-Code setzen
# Funktion 0 (exit) auswählen
# syscall

Problem 3: Recherchieren Sie (Bewertete Aufgabe)
Hinweis: Statt der Summe das Produkt zu berechnen, würde die Fakultät berechnen, 5000! sprengt ein 32-
bit Register aber um ein Vielfaches. Daher bleiben wir hier bei der Summe.
Auf dem Institutsrechner andorra benötigt die handgeschriebene Assembler-Funktion grob
5000 CPU-Zyklen, die kompilierte C-Version hingegen um die 30000.
Kompiliert man das Programm hingegen mit der stärksten Optimierung (gcc -O3 -m32
assembler.S framework.c), benötigt die kompilierte C-Version nur noch knapp 200 Zyklen.
Woran liegt das?
Betrachtet man diese simple Variante der gauss-Summe:
int main() {
int a = 5000;
int x = 0;
for (; a; a--) {
x += a;
}
return x;
}
und lässt sich die generierte Assembler-Datei einmal mit und einmal ohne Optimierung
anzeigen, so sieht man die folgenden beiden Programme:
ohne Optimierung -O3
.file "gauss-super-simple.c"
.text
.globl main
.type main, @function
main:
leal 4(%esp), %ecx
andl $-16, %esp
pushl -4(%ecx)
pushl %ebp
movl %esp, %ebp
pushl %ecx
subl $16, %esp
movl $5000, -12(%ebp)
movl $0, -8(%ebp)
jmp .L2
.L3:
movl -12(%ebp), %eax
addl %eax, -8(%ebp)
subl $1, -12(%ebp)
.L2:
cmpl $0, -12(%ebp)
jne .L3
movl -8(%ebp), %eax
addl $16, %esp
popl %ecx
popl %ebp
leal -4(%ecx), %esp
ret
.size main, .-main
.file "gauss-super-simple.c"
.text
.p2align 4,,15
.globl main
.type main, @function
main:
leal 4(%esp), %ecx
andl $-16, %esp
pushl -4(%ecx)
movl $12502500, %eax
pushl %ebp
movl %esp, %ebp
pushl %ecx
popl %ecx
popl %ebp
leal -4(%ecx), %esp
ret
.size main, .-main
Die Unterschiede sind lila hervorgehoben.
In der linken Variante erkennt man die
Schleife. Da sie aber immer das gleiche
ausgeben wird (12502500 nämlich), wurde
in der optimierten Variante diese Schleife
vom Compiler direkt durch den Wert
ersetzt.

TI II - Uebung 2
Felix Herter, Moritz Niklas Paul
May 12, 2011
1 Aufgabe 3
Kompiliert man die framework.c erhält man für die Berechnung der Gaußschen Summe von n = 5000 die
Taktzahlen:
Assembler: 10944
C: 60780
Der geringere Rechenaufwand der Assemblerfunktion ist leicht zu erkennen, auch wenn das auf dem Heimrechner
(Intel(R) Core(TM)2 CPU 2.00GHz ) erzielte Verhältnis von ca. 1:6 auf den Uni Rechnern nicht zu reprodizieren
war (Verhältnis von ca. 1:2).
Die folgenden Codeauszüge zeigen die geänderten Stellen des Ursprungsprogramms, sodass sie nun die Fakultät
anstelle der Gaußschen Summe ausgeben.
Assembler:
mov %eax, %ecx
dec %ecx
1:
imul %eax, %ecx
dec %ecx
jnz 1b
C: int fak(int a){
int x=1
for(;a;a--){
x*=a;
}
return 0;
So weit so gut, die entsprechende Ausgabe für die Berechnung der Fakultät von n = 13 liefert folgende Taktzahlen:
Assembler: 708
C: 960
Auch hier ist der Assembler schneller, wenn auch nicht mehr ganz so eindeutig wie bei der Summenberechnung,
welche jedoch auch mit einem deutlich größeren Parameter aufgerufen wurde.
Kompilieren wir nun die framework.c zusätzlich mit der Optimierungsflag -O3, so erwarten wir, dass der C-
Code schneller laufen wird als der Assembler-Code. Auf jeden Fall zumindest schneller, als vor dem Setzen der
Flag. Die Ausgabe hingegen straft unsere Naivität mit den Werten:
1

Assembler: 577723137680999036
C: 166200
Allein ein Blick auf die angebliche Anzahl der benötigten Takte, welche die Assemblerfunktion benötigt haben
soll zeigt, dass es hier wohl nicht mit rechten Dingen zugehen kann: Bei den 2GHz des benutzten Prozessors
ist es Recht unwahrscheinlich, dass in den Sekundenbruchteilen, die die Berechnung gedauert hat, über 5 · 10 17
Takte stattgefunden haben. . . Leider war es auch auf anderen Rechnern (Netbook, Unirechner) nicht möglich
zufriedenstellende Ergebnisse zu erzielen.
Aufgrund erheblich Zeitmangels (ALP2 Klausur) konnten wir uns nicht so ausgiebig mit den optimierten Assemblercodes
auseinandersetzen (der des framework.c betrug 134 Zeilen(!)). Zur Vereinfachung haben wir eine
separate fakultaet.c geschrieben, die die Fakultät von 13 ausgibt. Optimieren und dissassemblieren führten
zu:
.file "fakultaet.c"
.section .rodata.str1.1,"aMS",@progbits,1
.LC0:
.string "13! = %i\n"
.text
.p2align 4,,15
.globl main
.type main, @function
main:
pushl %ebp #Basepointer wird auf den Stack gespeichert
movl %esp, %ebp #Basepointer wird auf Stackpointer gesetzt (AT&T?)
andl $-16, %esp #ist %esp==-16 ?
subl $16, %esp
movl $1932053504, 8(%esp) #Der Compiler hat den Wert bereits ausgerechnet(!)
und speichert diesen in der Adresse, auf die %esp
gerade Zeigt (reserviert 8 Speichereinheiten?)
movl $.LC0, 4(%esp)
movl $1, (%esp)
call printf chk
xorl %eax, %eax #effizient %eax auf 0 gesetzt?
leave
ret #%eax-Wert wird zurückgegeben?
.size main, .-main
.ident "GCC: (Ubuntu 4.4.3-4ubuntu5) 4.4.3"
.section .note.GNU-stack,"",@progbits
Unsere spartanischen Vermutungen stehen als Kommentar hinter den jeweiligen Anweisungen. Allerdings
ist vielleicht noch erwähnenswert, dass der Compiler selbst anscheinen bereits gesehen hat, dass das Ergebnis
1932053504 betragen wird, und dies nun einfach auf dem Stack speichert, anstatt die tatsächliche Implementierung
der fakultaet.c im Assemblercode wieder zu spiegeln.
2