Auch auf die Gefahr hin, daß ich gesteinigt werde. Aber ich bin gerade
dabei mich in Assembler einzuarbeiten und eine ausgiebige
Google-Recherche sowie Forensuche hat meine Frage nicht wirklich
beantwortet.
Mir ist klar, daß in der Section .text der Programmcode steht und in
.data die initialisierten Variablen. Auch, daß im .bss nicht
initialisierte Variablen stehen, die erst zur Laufzeit dort abgelegt
werden.
Doch eine dumme Frage: Was bringt die Unterscheidung von .text und .data
überhaupt? Speziell, wenn ich einen Controller mit so viel externem RAM
habe, daß mein gesamtes Programm da locker reinpaßt.
Die Frage hat auch einen Grund: Für die Portierung eines großen
ASM-Projekts wünsche ich mir folgendes: Ich möchte, daß bestimmte
Befehle oder Konstanten an einer definierten Adresse stehen, die sich
aus der Geschichte des vorhandenen Codes ergibt.
Mit .org kann ich den Anweisungszähler weiter schieben (aber leider
nicht mehr zurück!!). Das ist also der falsche Weg.
Könnte man nicht durch Definition von Sections (.meineAdresse1,
.meineAdresse2, ...) und ein passendes Linkerscript entsprechend Einfluß
nehmen?
Also mit einem Linkerscript der Art:
.meineAdresse1:
{
. = 0x1234567
und sonst ??
}
Nebenbei: Zielplattform ist ein MCF548X, also Coldfire.
Da sich die Zahl der Antworten bisher in Grenzen hält: Ist die Frage zu trivial oder zu unverständlich? Vielleicht kann sich ja doch ein Assembler-Spezialist erbarmen und mich nicht dumm sterben lassen? Also: Was bringt die Unterscheidung zwischen .text und .data?
Michael wrote: > Also: Was bringt die Unterscheidung zwischen .text und .data? Das hängt von deinem Zielsystem ab. Ist es eine Harvard- Architektur wie z. B. der AVR, sollte die Antwort offensichtlich sein: es wird dabei über die Ausführbarkeit des Codes entschieden. Ist dein Zielsystem eine VM-Architektur, dann kann der Fall sehr ähnlich sein: die MMU kann bestimmte Speicherbereiche separat als ausführbar markieren, andere nicht. Andererseits kann der ausführbare Code im Gegenzug auch schreibgeschützt werden, sodass er sich nicht selbst überschreiben kann. Minimal erreichst du zumindest eine sinnvolle Gruppierung: der Linker gruppiert alle Funktionen und alle Daten separat zusammen. Manche Tools können sich dann darauf beziehen, bspw. kann der Disassembler darauf verzichten, die Datenbereiche zu disassemblieren.
Michael wrote: > Da sich die Zahl der Antworten bisher in Grenzen hält: Ist die Frage zu > trivial oder zu unverständlich? Naja, ich denke, diese crazy Masochisten, die sich nen 32Bit-Boliden noch mit Assembler reinziehen, dürften fast ausgestorben sein. Ich für meinen Teil benutze überwiegend 8Bitter und habe da ne klare Grenze gezogen: Bis max 2kB Binärfile kann man noch in Assembler proggen, aber darüber steigt der Aufwand, den Überblick zu behalten, rapide und der Nutzen geht gegen Null. Bei C-Projekten habe ich anfangs versucht, einiges in Asembler zu machen, aber das macht in der Regel mehr Probleme, als es löst. Es gibt nichts, was sich nur in Assembler lösen läßt. > Vielleicht kann sich ja doch ein Assembler-Spezialist erbarmen und mich > nicht dumm sterben lassen? > Also: Was bringt die Unterscheidung zwischen .text und .data? Für mich sind es nur Compiler-Internas, von denen ich nicht wissen muß, was die Compilerbauer sich dabei gedacht haben. Peter
@ Jörg Danke für die Ausführung. Jetzt sehe ich klarer. @ Peter > Naja, ich denke, diese crazy Masochisten, die sich nen 32Bit-Boliden > noch mit Assembler reinziehen, dürften fast ausgestorben sein. Stimmt! Ich komme ja auch von der C-Schiene und war damit bisher immer nah genug an der Hardware für meine Projekte. Aber wenn man schon ein entsprechend großes Projekt hat, dann will man es auch nicht auf den Müll schmeißen! Ein neues Projekt dieser Art in Assembler würde ich auch nicht anfangen. Außerdem ist das Prinzip ja auch bei kleineren Controllern gleich. Darum dachte ich, die Assembler- und Linker-Script-Spezialisten könnten mir da helfen. Bisher habe ich mich mit Startup-Code, Linker-Script und solchen Sachen einfach noch nicht genug beschäftigt. C rein, hex raus klappte mit WinAVR recht problemlos. Aber man will ja seinen Horizont erweitern. >> Vielleicht kann sich ja doch ein Assembler-Spezialist erbarmen und mich >> nicht dumm sterben lassen? >> Also: Was bringt die Unterscheidung zwischen .text und .data? > Für mich sind es nur Compiler-Internas, von denen ich nicht wissen muß, > was die Compilerbauer sich dabei gedacht haben. Das dachte ich anfangs auch. Als sich dann die Frage stellte, wieviel SRAM und Flash ich noch übrig habe, da wurden .text, .data und .bss interessant. Und wie gesagt, man will ja auch wissen, was in der Blackbox wirklich passiert. Auch wenn man die Vorteile einer Hochsprache nutzt, bei der Controllerprogrammierung ist es schon recht nützlich auch die Grundlagen zu kennen. Michael
Michael wrote: > Das dachte ich anfangs auch. Als sich dann die Frage stellte, wieviel > SRAM und Flash ich noch übrig habe, da wurden .text, .data und .bss > interessant. Da gibt es grundlegende Unterschiede zwischen den Compilern. Ich habe mit dem Keil C51 angefangen und da werden die lokalen Variablen überlagert, da ja der Stack des 8051 nicht so doll ist. Daraus ergibt sich der Vorteil, daß man im Map-File sehr gut die exakte Speicherauslastung erkennen kann. Beim AVR-GCC werden dagegen lokale Variablen auf dem Stack angelegt und tauchen damit nicht in der Compilestatistik auf. Da behelfe ich mich damit, daß ich ne Funktion aufrufe, die den freien SRAM bis zum SP mit einem Muster füllt (0x77) und prüft, wieviel davon beim nächsten Aufruf noch übrig ist. Man läßt also das Programm ne Weile laufen und gibt dann diesen Wert aus. Das geht allerdings nur, solange kein Malloc verwendet wird. Peter
@ Peter Dannegger (peda) >Bis max 2kB Binärfile kann man noch in Assembler proggen, aber darüber >steigt der Aufwand, den Überblick zu behalten, rapide und der Nutzen >geht gegen Null. Weichei ;-) Hast Recht. Ich hab vor Jahren mal ein Programm auf nem 8515 geschrieben, ASM, ca. 88kB Quelltext, 90% vom Flash voll. Das hab ich jetzt mal in C konvertiert, nur minimale funktionale Änderungen. Und es passt gerade noch so rein, 98,5% Flashauslastung. Aber es ist um Längen besser lesbar. Mein Respekt an AVR-GCC!! MfG Falk
Falk Brunner wrote: > Weichei ;-) > Hast Recht. Ich hab vor Jahren mal ein Programm auf nem 8515 > geschrieben, ASM, ca. 88kB Quelltext, 90% vom Flash voll. Das hab ich > jetzt mal in C konvertiert, nur minimale funktionale Änderungen. Und es > passt gerade noch so rein, 98,5% Flashauslastung. Aber es ist um Längen > besser lesbar. > Mein Respekt an AVR-GCC!! Und unter Umständen sogar schneller. Abhängig von deinen Assemblerkünsten ;)
@ Simon K. (simon) Benutzerseite >Und unter Umständen sogar schneller. Abhängig von deinen >Assemblerkünsten ;) Nananana junger Freund, du spielst mit deiner ohnehin dürftigen Rente . . . ;-) MfG Falk P.S. Geschwindigkeit ist bei dem Programm sowieso drittranging. Das ist eine einfache Schiedrichteranlage + Stopuhr, läuft als State Machine mit 100 Hz. Hat zu 99,99% nix zu tun, nur ein paar Zeiten runterzählen und ab und an ein LCD refreshen. To whom it may concern. http://www.torpedo-dresden.de/hupanlage.php?details=2 Die zweite Version unten auf der Seite.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.