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 ?
...sind eventuell einige von den lokalen Variablen als static deklariert? ;-)
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 -.-
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.
Kostenlose Software benutzen und trotzdem noch meckern... ;)
Im oben verlinkenten Beitrag steht auch ein einfacher Workaround dazu. Einfach das Codeschnipsel in den Source aufnehmen, und "gut iss". Frank
>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.
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?
Er meint bestimmt FreePascal. Das würde alle seine Äußerungen erklären, denn wer so eine Programmiersprache nutzt...
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. ;-)
@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.
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.
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.
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.
>[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
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.
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.
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.
Ja, habs schon geändert ich hab einfach nicht dran gedacht. Wieder mal son Fall von Wald vor lauter Bäumen nicht gesehn.
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.