www.mikrocontroller.net

Forum: Compiler & IDEs Was bringen .text .data (und .bss) bei Assembler ?


Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.