www.mikrocontroller.net

Forum: Compiler & IDEs Riesen datensegment


Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Ich hab gestern meine toolchain auf das neue winavr (gcc 4.2) 
umgestellt.
Jetzt ist plötzlich das Datensegment bei einigen meiner Projekte bis zum 
umfallen aufgebläht. Ich hab hier z.b. 2 .c files die jewails so um die 
10 Funktionen enthalten. Wenn ich die mit ins Projekt einkompiliere wird 
das Datensegment plötzlich um 1K!! grösser.
Es gibt in beiden Files keine einzige globale Variable.
Nur lokale in den routinen die dürften ja aber eigentlich nur Einfluss 
auf den Stack haben.

hat jemand eine Idee was hier passiert ?

Autor: Der Albi (der-albi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...sind eventuell einige von den lokalen Variablen als static 
deklariert? ;-)

Autor: OliverSo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

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

Bewertung
0 lesenswert
nicht lesenswert
Strings?

Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke, in einer routine wird mit 2 Floats gerechnet.
Auskommentiert-> 400 byte weniger ram.
Das ist einfach nur krank ich zieh mir jetzt wieder nen gcc 3.x und hoff 
das mein geliebter fpc bald n target für den avr hat dann bin ich den 
müll mit gcc und der gnu toolchain los -.-

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

Bewertung
0 lesenswert
nicht lesenswert
Ist natürlich einfacher, auf andere zu hoffen, als sich an die
Analyse eines Problems zu machen...

Falls du die 256 Bytes für irgendeine konstante Tabelle meinst, das
ist ein bekannter Bug, der mittlerweile schon repariert ist und nur
drauf wartet, dass WinAVR ein neues Release rausbringt.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kostenlose Software benutzen und trotzdem noch meckern... ;)

Autor: Frank B_. (frank_b) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im oben verlinkenten Beitrag steht auch ein einfacher Workaround dazu.
Einfach das Codeschnipsel in den Source aufnehmen, und "gut iss".

Frank

Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ist natürlich einfacher, auf andere zu hoffen, als sich an die
>Analyse eines Problems zu machen...

hast du meine Beiträge nicht gelesen oder ignoriert ? Das Problem ist 
doch bekannt ...

>Kostenlose Software benutzen und trotzdem noch meckern... ;)

Darf man nicht allzu ernst nehmen ich erwarte nur immer recht viel vom 
gcc da alle Welt ihn nutzt und solche Probleme erwartet man dann einfach 
nicht. Bin das einfach vom fpc nicht gewohnt und wenn dann sowas im gcc 
auftaucht der zig mal verbreiteter ist enttäuscht mich das.

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

Bewertung
0 lesenswert
nicht lesenswert
Christian Ulrich wrote:

> hast du meine Beiträge nicht gelesen oder ignoriert ?

Ich finde in deinen Beiträgen nicht einmal ansatzweise den Versuch
einer Analyse, was genau denn passiert wäre.  Ohne diese Analyse
kann man aber auch keine Hilfe leisten.  Wie schon geschrieben, die
Ursache von 256 Bytes in __clz_tab[] sind bekannt (und der Fehler
mittlerweile beseitigt), für den Rest müsstest du schon selbst mit
helfen.

Einfach nur meckern kann jeder.  Was ist, wenn dich den fpc (was
auch immer das sein mag, ist mir noch nicht übern Weg gelaufen) beim
nächsten Versuch mit was anderem enttäuscht?  Schnell weg, das
nächste gesucht, neue Probleme?

Autor: Terminator (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Er meint bestimmt FreePascal.
Das würde alle seine Äußerungen erklären, denn wer so eine 
Programmiersprache nutzt...

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

Bewertung
0 lesenswert
nicht lesenswert
Naja, daran würde ich es nicht festmachen.  Pascal hat in Form von
Turbopascal die Programmierung unter CP/M durchaus revolutioniert.

Real Programmers can write FORTRAN programs in any language. ;-)

Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Terminator
Schau dir erstmal an über was du da urteilst.
Pascal is ne sehr schöne und vor allem lesbare Sprache.
Aber das ist nicht Thema des Threads und ich weiss dont feed the Trolls.

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

Bewertung
0 lesenswert
nicht lesenswert
Christian Ulrich wrote:

> Pascal is ne sehr schöne und vor allem lesbare Sprache.

Ich kann's nur wiederholen:

Real Programmers can write FORTRAN programs in any language.

Es ist nicht die Programmiersprache selbst, die "lesbar" ist oder
nicht, sondern das, was der Programmierer draus macht.  Man kann
unleserliche Pascal-Programme genauso verfassen wie gut lesbare
C-Programme.

> Aber das ist nicht Thema des Threads ...

Zu dem du dich allerdings offenbar nicht mehr äußern willst.  Anders
kann ich es jedenfalls nicht deuten, dass du nach wie vor nichts hier
zeigst, was man als Ursachenanalyse benutzen könnte, um dir ggf. die
notwendige Hilfe zuteil werden zu lassen.

Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry, für mich ist das Problem erstmal erledigt gewesen es war 
anscheinend die Tabelle im Ram, die das Datensegment aufgebläht hat.

Jedoch hab ich immernoch keine Erklärung dafür wiso mein Datensegment 
überhaupt so groß ist. Ich hab max. 1K globale Variablen warscheinlich 
weit weniger. und die 4K vom Atmega64 sind zu 98% voll. Der Code ist 
recht stark gekapselt was sich jedoch nur auf den Stack auswirken sollte 
meines erachten nach.
Hat dazu jemand eine Idee ?

Und @Jörg du hast schon recht das es auch auf den Programmierer ankommt 
aber man kann z.b. in Visual Basic einfach keine lesbaren Programme 
schreiben in C ists sehr schwer. In Pascal ists nahezu unmöglich 
unleserlich zu schreiben. Tut trotsdem nichts zur Sache.

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

Bewertung
0 lesenswert
nicht lesenswert
Christian Ulrich wrote:

> Ich hab max. 1K globale Variablen warscheinlich
> weit weniger. und die 4K vom Atmega64 sind zu 98% voll.

Warum mutmaßt du immer noch, statt nachzugucken?  Für sowas gibt's
Symboltabellen, die man sich ansehen kann -- aber die hast du,
nicht wir.

Autor: Mario (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>[bla bla-Output eines z0m3ie-Hirns]
>Hat dazu jemand eine Idee ?

Du glaubst nicht im Ernst, dass dir noch jemand Ideen liefert, was? Du 
hast nicht nur in diesem Thread bewiesen, dass du immer wieder Loesungen 
verlangst, ohne das Problem vernuenftig zu beschreiben.

Und wenn jemand deine duerftigen Informationen so interpretiert, dass 
daraus eine sinnvolle Fragestellung wird, und diese freundlicherweise 
beantwortet, machst du ihn nieder.

Es wird Zeit, Christian Ulrich aka z0m3ie forumsweit zu ignorieren.

Mario

Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wo hab ich denn bitte jemanden niedergemacht ?
Die Farge die noch übrig ist, war lediglich warum gcc lokale Variablen 
ins Datensegment wirft statt auf den Stack. Das ist nicht 
projektspezifisch.
Was hab ich nicht beschrieben ?
ich werde lediglich grantig wenn 50 Gäste sie zu feige sind sich am 
forum anzumelden die Threads mit Sachen zumüllen die überhaupt nichts 
mit der Fragestellung zu tun haben bzw die Fragesteller beleidigen. Das 
ist hier eine absolute Unart.
Wenn dazu niemand eine Idee hat ists doch ok. Es war lediglich eine 
Frage. Es fehlen auch keine Informationen wenn doch kann man die 
anfragen. Falls ich mich undeutlich ausgedrückt haben sollte tut mir das 
leid.

Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hatte Jörgs Beitrag (3.) total übersehn ...

>Strings?

Genau so. Absoulut logisch das die im Datensegment landen und aus dem 
map file schlecht zu ersehn gewesen :|. Danke.

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

Bewertung
0 lesenswert
nicht lesenswert
Christian Ulrich wrote:

>>Strings?
>
> Genau so. Absoulut logisch das die im Datensegment landen

Eine Folge der Harvard-Architektur in Verbindung mit dem C-Standard.
Der möchte ja, dass deine Strings aufrufkompatibel zu Standardfunktionen
wie strcmp() etc. sind.  Damit kann der Compiler sie nur im RAM
ablegen, denn nur dort sind sie mit beliebigen anderen const char *
Objekten austauschbar.

Tutorials für Strings (und andere Daten) im Flash-ROM sollte es
ausreichend geben.

Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, habs schon geändert ich hab einfach nicht dran gedacht.
Wieder mal son Fall von Wald vor lauter Bäumen nicht gesehn.

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.