|
|
GRUNDLAGEN DER INFORMATIK WS 0203 - Vorlesung |
1. Informatik im Licht von IT2006
In der ersten Vorlesung hatten wir uns mit dem Bild vertraut gemacht, das vom Bundesministerium im Rahmen des neuen Forschungsprogramms IT2006 für die Informations und Kommunikationsindustrie in den nächsten vier Jahren gezeichnet wird:
IT2006-Sicht auf die Informatik 2002-2006
Wir wollen diese Sicht jetzt durch eine andere Sicht ergänzen.
2. Eine Informatik-Themenkarte aus Sicht der 'typischen' Einsatzsituation
Diese andere Sicht geht aus von den 'Realisierungssituationen', wie sie aus Sicht des 'Informatikers vor Ort' erscheinen.
Informatik-Themenkarte
3. Die Verwandlung von Weltausschnitten in Bits und Signale
Wie man aus der vorausgehenden Themenkarte zur Informatik schon erkennen kann, besteht eine Leistung der Informatik daran, bestimmte problemorientierte Ausschnitte der realen Welt in einem mehrstufigen Prozess so zu übersetzen (transformieren), dass dieses Problem am Ende in Form von Bitfeldern vorliegt, die implizit eine solche Befehlsstruktur kodieren, dass eine Maschine (ein Mikroprozessor), diese Bitfelder in ein gewünschtes Verhalten umsetzt. Es beginnt mit normalsprachlicher Kommunikation unterstützt durch Aufzeigesituationen, Gesten, Grafiken, Bildern, Beispiele von Handlungsabläufen usw. Es entstehen vereinbarte Texte ('Lastenhefte'); diese werden in unterschiedliche abstrakte Konzepte/ Modelle/ Strukturen übersetzt (völlig betriebssystemunabhängig); diese dann wieder in verschiedene Programmiersprachen (nahezu betribssystemunabhängig); und der Quellkode der Programmiersprachen wird dann stufenweise weiter übersetzt in Assemblerkode (noch vergleichsweise unabhängig von einem bestimmten Prozessor), und dann in den Objektkode (Binärekode) eines konkreten Prozessors. Der Prozessor besteht aus physikalischen Gattern, die durch die Verteilung und den Fluss elektrischer Ladungen charakterisierbar sind. Damit erreicht die kodierte Welt den Bereich kontrollierter elektrischer Signale. Wie diese physikalischen Signale technisch realisiert werden, das ändert sich nahezu von Tag zu Tag. Die Grundlagenforschung ist hier sehr in Bewegung. Letzteres ist auch dringend geboten, da die für die Produktion von Chips und Rechnern relevanten Weltrohstoffvorräte (Blei, Kupfer, Zink,...) nach Wissensstand vom Jahr 2002 in ca. 20-30 Jahren nicht regenerierbar erschöpft sein werden. Keine Chips, keine Computer, keine IT-Industrie, .... keine attraktive Perspektive.
Transformation eines Problems in Binaerkode
4. Beispiel: C-Quellcode -> Assembler -> Binärcode
Das folgende Beispiel soll jenen Abschnitt in der Übersetzung von einem Stück Realwelt in den Objektcode eines Mikroprozessors verdeutlichen, der bei dem Quellcode einer Hochsprache (hier 'C') beginnt, und dann über Assembler-Code zum Binär-Code führt. Dabei wird gebrauch gemacht von dem Assembler-Programm 'as' und dem Linker-Programm 'ld', wie es unter Linux zusammen mit dem GNU-C-Compiler 'gcc' standardmaessig zur Verfügung steht. Auf Details der Assemblerprogrammierung wird hier aber nicht eingegangen. Für Interessierte sei verwiessen auf die hervorragende Seite der Linux Assembler Organisation. Hier gibt es nicht nur eine umfassende Erklärung und Erörterung des Themas Assemblerprogrammierung (vor allem, warum man es möglichst vermeiden sollte!!!), sondern auch weitere Artikel, Beispiele und Programme.
/***************************************************************
*
* start.c
*
* author: gdh
* date: oct-8, 2002
*
* idea: Erstes einfaches Beispiel für ein einfaches C-Programm
* before: Keine
* after: Keine
* compilation: gcc -o start start.c
* usage: start
*
***************************************************************/
#include <stdio.h>
int main(void)
{
printf("Jetzt kommt es: \n\n");
printf("Das berühmte erste Hallo...\n");
printf("!!!!!!!!!!!!!\n");
return(0); /* auch möglich: return 0; */
}
Dieser C-Quellcode wird mit dem GNU-C-Compiler 'gcc' in ein Assamblerformat übersetzt, das von der Syntax her zur AT&T-Familie gehört, im Gegensatz zur Intel-Syntax. Doch gibt es Werkzeuge, beide Dateiformate ineinander zu übersetzen.
gerd@turing:~/WEB-MATERIAL/fh/I-EDV/VL2 > gcc -v -S start.cDer Compiler wird hier mit zwei Optionen aufgerufen: '-v' steht für 'verbose', d.h. der Vorgang der Übersetzung wird ein wenig kommentiert, und '-S' steht für 'Assemblermodus', d.h. das Ergebnis ist Code für den GNU-Assembler 'as' bzw. 'gas'; die Ergebnisdatei bekommt das Suffix '.s'.
Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.3/specs gcc version 2.95.3 20010315 (SuSE) /usr/lib/gcc-lib/i486-suse-linux/2.95.3/cpp0 -lang-c -v -D__GNUC__=2 -D__GNUC_MINOR__=95 -D__ELF__ -Dunix -D__i386__ -Dlinux -D__ELF__ -D__unix__ -D__i386__ -D__linux__ -D__unix -D__linux -Asystem(posix) -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ -Di486 -D__i486 -D__i486__ start.c /tmp/ccKXHEcc.i GNU CPP version 2.95.3 20010315 (SuSE) (i386 Linux/ELF) #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/lib/gcc-lib/i486-suse-linux/2.95.3/include /usr/include End of search list. The following default directories have been omitted from the search path: /usr/include/g++ /usr/lib/gcc-lib/i486-suse-linux/2.95.3/../../../../i486-suse-linux/include End of omitted list. /usr/lib/gcc-lib/i486-suse-linux/2.95.3/cc1 /tmp/ccKXHEcc.i -quiet -dumpbase start.c -version -o start.s GNU C version 2.95.3 20010315 (SuSE) (i486-suse-linux) compiled by GNU C version 2.95.3 20010315 (SuSE).
Dies erzeugt die Datei start.s.
gerd@turing:~/WEB-MATERIAL/fh/I-EDV/VL2> cat start.s
.file "start.c"
.version "01.01"
gcc2_compiled.:
.section .rodata
.LC0:
.string "Jetzt kommt es: \n\n"
.LC1:
.string "Das ber\374hmte erste Hallo...\n"
.LC2:
.string "!!!!!!!!!!!!!\n"
.text
.align 16
.globl main
.type main,@function
main:
pushl %ebp
movl %esp,%ebp
subl $8,%esp
addl $-12,%esp
pushl $.LC0
call printf
addl $16,%esp
addl $-12,%esp
pushl $.LC1
call printf
addl $16,%esp
addl $-12,%esp
pushl $.LC2
call printf
addl $16,%esp
xorl %eax,%eax
jmp .L2
.p2align 4,,7
.L2:
movl %ebp,%esp
popl %ebp
ret
.Lfe1:
.size main,.Lfe1-main
.ident "GCC: (GNU) 2.95.3 20010315 (SuSE)"
Dieser Assemblercode wird dann dem Assembler 'as' übergeben, der daraus Objektcode mit der endung '.o' erzeugt. Die Option '-a' fordert den Assembler auf, die Speicherbelegung mit aufzulisten.
gerd@turing:~/WEB-MATERIAL/fh/I-EDV/VL2 > as -a -o start.o start.s
GAS LISTING start.s page 1
1 .file "start.c"
2 .version "01.01"
3 gcc2_compiled.:
4 .section .rodata
5 .LC0:
6 0000 4A65747A .string "Jetzt kommt es: \n\n"
6 74206B6F
6 6D6D7420
6 65733A20
6 0A0A00
7 .LC1:
8 0013 44617320 .string "Das ber\374hmte erste Hallo...\n"
8 626572FC
8 686D7465
8 20657273
8 74652048
9 .LC2:
10 0030 21212121 .string "!!!!!!!!!!!!!\n"
10 21212121
10 21212121
10 210A00
11 .text
12 .align 16
13 .globl main
14 .type main,@function
15 main:
16 0000 55 pushl %ebp
17 0001 89E5 movl %esp,%ebp
18 0003 83EC08 subl $8,%esp
19 0006 83C4F4 addl $-12,%esp
20 0009 68000000 pushl $.LC0
20 00
21 000e E8FCFFFF call printf
21 FF
22 0013 83C410 addl $16,%esp
23 0016 83C4F4 addl $-12,%esp
24 0019 68130000 pushl $.LC1
24 00
25 001e E8FCFFFF call printf
25 FF
26 0023 83C410 addl $16,%esp
27 0026 83C4F4 addl $-12,%esp
28 0029 68300000 pushl $.LC2
28 00
29 002e E8FCFFFF call printf
29 FF
30 0033 83C410 addl $16,%esp
31 0036 31C0 xorl %eax,%eax
32 0038 EB06 jmp .L2
33 003a 8DB60000 .p2align 4,,7
33 0000
34 .L2:
35 0040 89EC movl %ebp,%esp
36 0042 5D popl %ebp
37 0043 C3 ret
38 .Lfe1:
39 .size main,.Lfe1-main
GAS LISTING start.s page 2
40 0044 8DB60000 .ident "GCC: (GNU) 2.95.3 20010315 (SuSE)"
40 00008DBF
40 00000000
GAS LISTING start.s page 3
DEFINED SYMBOLS
*ABS*:00000000 start.c
start.s:3 .text:00000000 gcc2_compiled.
start.s:15 .text:00000000 main
UNDEFINED SYMBOLS
printf
Der so erzeugte Objektcode ist aber noch nicht auf einer konkreten Maschine lauffähig. In ihm werden z.B. Routinen aufgerufen ('printf'), für die es noch keine Implementierung gibt. Diese fehlenden Code-Teile sowie die Einbindung dieses Codes in eine Ablaufumgebung, diese müssen noch hinzugefügt werden. Diese Aufgabe übernimmt der Linker 'ld'.
gerd@turing:~/WEB-MATERIAL/fh/I-EDV/VL2> ld -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o start /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/gcc-lib/i486-suse-linux/2.95.3/crtbegin.o /usr/lib/gcc-lib/i486-suse-linux/2.95.3/crtend.o /usr/lib/crtn.o start.o -lcDem Linker 'ld' wird mit der Option '-m elf_i386' gesagt, dass er eine Datei im Linux-Elf Format für Intel386-Architektur erstellen soll. Die Optionen '-dynamic-linker' und '/lib/ld-linux.so.2' besagen, dass shared Libraries (so) für dynamisches Linken geladen werden sollen. '-o start' legt fest, dass die endgültige Objektdatei 'start' heissen soll. Die nachfolgend aufgeführten '*.o'-Dateien sind sogenannte 'wrapper_Dateien', die die Einbindung des Objektcodes in die Ablaufumgebung sicherstellen sollen.
Will man wissen, wiviel Speicherplatz das endgültge Programm wirklich benötigt, dann kann man dies auch erfahren:
gerd@turing:~/WEB-MATERIAL/fh/I-EDV/VL2 > size starttext data bss dec hex filename 1035 224 24 1283 503 start
Insgesamt benötigt das Programm 1283 Bytes, davon alleine 1035 für Text, 224 für Daten und 24 Bytes für nichtinitialisierte Daten.
Will man wissen, wie der endgültige Objektkode mit allen Ergänzungen aussieht und wie er sich im Speicher verteilt, dann kann man sich mit dem Programm 'objdump' mit der Option '-d' für 'disassemble' den aktuellen Objectcode wieder 'rückübersetzen' lassen:
gerd@turing:~/WEB-MATERIAL/fh/I-EDV/VL2 > objdump -d start
