Interruptvektor im ATMEL-Datenblatt und im Compilat, Namen der Codeabschnitte in *.ls

[Peter(TOO)]

Hallo Geier,

Für ne Antwort/Erklärung danke ich schon jetzt.

Die Fragen zusammen:
1) Wieso heißt ein Programmabschnitt der *.lss ".text"? Wieso haben die andern Abschnitte ihre Namen? Ich finde leider dazu mit der Suche bei Google keine Antwort.
2) Wieso sind die Interruptvektoren im Datenblatt mit 2 inkrementierte, in der *.lss mit 4? Ok, das ist wohl der Adressraum des mega328 ! ? ! ?
3) Steht irgendwo ne (gute *gg*) Erklärung für Aufbau, Code-Abschnittnamen etc. der *.lls-Datei? Wo bitte?

Zu 1)
Das sind alte Geschichten aus den Anfängen von C.
Das Source-Programm wird dem Compiler als Text-Datei gefüttert.

.code wurde vor C schon für den Code von Assemblerprogrammen verwendet.
Also kam da einer auf die Idee, das Segment halt .text zu benennen, welches den Maschinencode des C-Programms enthält.
Das cstartup-Modul, welches die CPU-Register und noch ein paar Dinge initialisiert, bevor main() aufgerufen wird, ist meist immer noch in Assembler geschrieben und liegt typischerweise im .code-Segment.
.bss wird für statische Variablen verwendet.
.data enthält initialisierte statische variablen.
Dann gibt es oft noch .stack oder .cstack für den Bereich welcher den Stack enthält.

Die ganzen .debug_xxx-Segmente sind Metadaten für den Debugger und werden nicht auf dem Zielsystem abgelegt. Ein Sourcelevel-Debugger kann damit den Maschinen-Code mit dem Source-Code verknüpfen und alles entsprechend darstellen.

Grundsätzlich sind die Segmentnamen frei wählbar, es gibt halt aber Traditionen für deren Namen.

Bei einem µC werden .code, .text und .data im ROM abgelegt.
cstartup kopiert dann das .data-Segment ins RAM, somit haben alle Variablen einen Anfangswert.
.bss ist einfach der Bereich für statische Variablen ohne Initialisierung. Normalerweise füllt cstartup diesen Bereich des RAM mit Nullen.

http://www.atmel.com/webdoc/avrlibcr..._sections.html

Die Segmente braucht der Linker um die einzeln übersetzten Module zusammensetzen zu können. Im einfachsten Fall ist dies dein Programm und die Bibliotheks-Funktionen, bei grösseren Projekten wird auch das Anwendungsprogramm in mehrere Module aufgeteilt. Im Object-Code dieser Module gibt es noch keine absoluten Adressen, weil noch nicht bekannt ist, wo sie im Speicher zu liegen kommen.
Der Linker büschelt dann erst mal alles schön zusammen, also alle .text-Segmente werden in einem Block hintereinander gehängt, ebenso .data, .bss und all die anderen in jeweils ihrem Block. Anschliessend kann dann der Linker die absoluten Adressen generieren und an den richtigen Stellen im Code eintragen.
Module, welche besonders viel Stack benötigen, können dann auch noch ein entsprechend grosses Stack-Segment reservieren.

Zum Linker gehört auch noch eine Steuer-Datei. In dieser kann man ablegen auf welchen Adressen ROM und RAM im Speicherbereich abgelegt sind und welche Segmente wo abgelegt werden sollen.
Wenn man dies beherrscht kann man recht tolle Sachen machen! z.B. kann man die Datensegmente von der niedrigsten RAM-Adresse aus ablegen und das Stack-Segment von der höchsten RAM-Adresse aus. Da normalerweise der Stack von oben nach unten wächst hat man die grösste Sicherheit gegen einen Stackoverflow. Alles nicht belegte RAM befindet sich dann zwischen Daten und Stack. Bei besseren Linkern müssen der RAM- und ROM-Bereich auch nicht zusammenhängend sein, bei richtiger Konfiguration der Steuerdatei macht das dann der Linker automatisch.

Zu 2)
http://www.atmel.com/images/Atmel-82...t_Complete.pdf
ATmega 48A/48PA und ATmega88A/88PA haben 2 Byte für den Vektor.
ATmega168A/168PA und ATmega328/328P haben 4 Byte.
Abschnitt 2.2, Seite 7.

Zu 3)
Das ist eine harte Frage!
Es gibt kaum grundlegende Werke zu Linkern. Da ist man halt Profi und kommt mit den technischen Angaben zurecht. War irgendwie schon immer so
Hier mal eine Einführung in den Linker:
http://www.seceng.informatik.tu-darm...binder0910.pdf

Etwas älter (1972) aber ausführlicher:
http://www-inst.eecs.berkeley.edu/~c...ker-loader.pdf

Allerdings weiss ich noch nicht, welche Info dir zum Linker wirklich fehlen?
Scheint aber noch einiges an Grundlagen zu fehlen.

MfG Peter(TOO)

[oberallgeier]

@Gast: Danke für die Hinweise.

Peter: Danke für diese Ausführlichkeit und vor allem dafür, dass Du Dir die Zeit genommen hast mir das so gründich aufzuschreiben. Und das zu so später/früher Stunde! Danke.

.. Scheint aber noch einiges an Grundlagen zu fehlen ..

Genauso ist es. Was nutzt der ganze Kernighan-Ritchie? Einmal habe ich den sowieso nur teilweise parat, aber mir fehlt dazu eben der ganze Hintergrund zu der IDE. In früheren Jahren hab ich grad mal FORTRAN gelernt (Eingabe noch über Stapel dieser 80spaltigen Hollerith-Lochkarten ... im Nebenzimmer stand der alte 750-Bit-Trommelspeicher von Zuse im Waschmaschinenformat). Damals und später aber eigentlich nie wirklich was erfahren zu den nachgeschalteten Dingen wie Parser, Recognizer, Zwischencode, Linker und Loader. Da gibts noch endlos weite weiße Flecken . . .

......Bild hier  
......©Ausdrückliche Freigabe durch die Geschäftsleitung der GIZEH Werke mit Mail vom 27.11.09

.. Allerdings weiss ich noch nicht, welche Info dir zum Linker wirklich fehlen ..

Blöde Anwort: ich auch nicht. Aber ich arbeite an der Fragestellung.

[Peter(TOO)]

Peter: Danke für diese Ausführlichkeit und vor allem dafür, dass Du Dir die Zeit genommen hast mir das so gründich aufzuschreiben. Und das zu so später/früher Stunde!

Ich weiss ja selbst nicht ob es früh oder spät war, bei meinem Schlafrhythmus :-P

Genauso ist es. Was nutzt der ganze Kernighan-Ritchie?

K&R nutzt die bei deine Frage eigentlich gar nichts!
Der ursprüngliche C-Compiler bestand nur aus Parser und Code-Generator. Der Preprozessor kam erst später und war auch ein eigenes Programm.
Der Code-Generator lieferte dann einen Assembler-Sourcecode. Die weiteren Schritte waren dann Assembler und Linker und ein lauffähiges Programm zu erhalten. Allerdings wurden diese Programme als bekannt vorausgesetzt und von K&R gar nie beschrieben.
Es gab noch einen Pascal-Compiler zu dieser Zeit, der hat von Pascal in C übersetzt!

Um etwas über den Linker zu erfahren, muss man in der Assembler-Literatur forschen. Da gab es aber eigentlich noch keine Vorschriften zu den Segmentnamen. Sehr Hilfreich ist auch noch die Literatur über Mixed-Programming.

Mein grosser Vorteil ist, dass ich über die Hardware-Seite zum Programmieren kann, zuerst über Assembler. Zudem war das auch eine Zeit (1975), als man noch Stolz war 2KByte RAM zu besitzen
Da war noch alles Übersichtlich, I/O-Adressen und Monitor-Einsprungs-Punkte hatte man noch als Hex-Adresse im Kopf.

Zudem habe ich Programmiersprachen irgendwie immer erst verstanden, wenn ich gesehen habe, was die als Assembler-Code erzeugen.
Der Disassembler war mein grösster Freund, beim Lerner einen neuen Sprache

Einmal habe ich den sowieso nur teilweise parat, aber mir fehlt dazu eben der ganze Hintergrund zu der IDE.

Die IDEs sind wieder so eine Geschichte

Eigentlich ist immer noch alles wie Früher, mit den ganzen einzelnen Programmen Compiler, Linker usw. oft besteht auch der Compiler noch aus den einzelnen Programmen.
Die IDE erzeugt automatisch die Steuerdateien für diese Programme und ruft sie dann auch automatisch in der richtigen Reihenfolge auf.
Grundsätzlich kann man die IDE auch wegwerfen und alles zu Fuss aufrufen, bzw. Batch-Dateien schreiben, welche alles auch etwas automatisieren.

Ich hatte früher eine Sammlung von Batch-Dateien und einen Editor, als "IDE", aus welchem man externe Programme aufrufen konnte. Damit habe ich auch noch gearbeitet als IAR ihre IDE herausbrachte. War für mich einfacher, als erst zu lernen wie die IDE funktioniert.

Blöde Anwort: ich auch nicht. Aber ich arbeite an der Fragestellung.

Vielleicht trägst du mal zusammen was du weisst! Dann sieht man was so fehlt und kann die Fragen stellen

Hmm.., vielleicht sollte ich auch mal versuchen dazu einen Grundlagenkurs zu erstellen?
Wird dann aber vermutlich nicht auf einen bestimmten Compiler oder eine CPU ausgelegt sein.

MfG Peter(TOO)

[oberallgeier]

.. Es gab noch einen Pascal-Compiler zu dieser Zeit, der hat von Pascal in C übersetzt! ..
.. Vielleicht trägst du mal zusammen was du weisst! Dann sieht man was so fehlt und kann die Fragen stellen ..
.. Hmm.., vielleicht sollte ich auch mal versuchen dazu einen Grundlagenkurs zu erstellen? ..

Danke! Ach, Pascal in C, was Ähnliches kenn ich - (m)ein Freund hatte sich nen Übersetzer gebaut von FORTRAN nach C *gg*. Sicherlich wäre ein Grundkurs, evtl. im RNWissen schon prächtig. Aber es sind ja nicht lauter so C-Noobs hier wie ich.
Also zum Linker weiß/denke/vermute ich, dass er die relokativen (?) Codeteile zusammenfügt auf absolute Adressen setzt. Aber schon die Aufgabe ein Stück Assemblercode in einen C-Code einzufügen ist für mich nicht machbar. Zumal meine Bedienung des Studio4/WinAVR darin besteht, die Current Configuration Options auszufüllen - mein Make-File generiert bisher IMMER das Studio; die entsprechenden Befehle sind mir ein Rätsel.
Ich werde mich mal da einlesen (müssen) - und melde mich dann mit Fragen. Nicht diese Woche . . .