Hat AVR-GCC Probleme mit grossen Dateien?

block storage segment

Sprich: Für deine sämtlichen globalen Variablen größenmäßig ausreichend reservierter, aber nicht mit bestimmten Werten vorinitialisierter RAM.

Heiko Nocon schrieb:

Der Historie nach wohl "block starting symbol", weil irgendeine Maschine sowas mal als Assembler-(Pseudo-?)Befehl hatte. Ist natürlich ein nichtssagender Name, aber er hat sich für die nichtinitialisierten Daten gehalten.

--
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

Vielleicht _muss_ er einfach relativ springen, weil das relozierbarer Code ist?

Markus

Und da liegt der Hase im Pfeffer: Das sind 'ausführbare' Daten, d.h. die werden erst zur Laufzeit _irgend- wo_ in den Speicher kopiert und _können_ daher nur relativ springen, und das geht nun mal nur bis 64k (ein c166/167 kann dann z.B. nur

-128/+127).

Du musst den Code einfach kleiner machen.

Markus

Nicht unbedingt. Es könnte auch reichen, ihn "umzusortieren". Also die Reihenfolge von Codeteilen so zu ändern, daß alle Sprünge kurz genug werden. Schlimmstenfalls kann auch noch zusätzlicher Code eingefügt werden, der zu weite Sprünge quasi in mehrere Etappen aufteilt.

Letzteres geht natürlich auf Kosten der Laufzeiteffizienz.

Das meinte ich.

Sowas hab' ich mal machen müssen, es lief in etwa auf folgendes raus (der Code musste relozierbar sein, da er zur Laufzeit aus dem Flash in's RAM geladen werden musste; seine Aufgabe war nämlich, den Flash neu zu beschreiben):

Code (hier muss man sich halt den passenden Maschinencode vorstellen) LabelAnfang: Code Code : : : jr weiter LabelSprung: jr LabelAnfang weiter: Code ... : : jr LabelSprung

You get the picture.

Dummerweise kam keine Warnung oder sonstwas, wenn der Code innerhalb der Schleifen zu lang wurde, sondern der Compiler baute einfach ein jmpa (absolute Jump) anstatt eines jr (jump relative) ein. Er konnte ja nicht wissen, daß die Routine relozierbar sein musste, bzw. ich wusste damals nicht, wie ich es dem Compiler beibiege.

Markus

Oops? Können die AVRs überhaupt Code aus dem RAM ausführen? AFAIK nein, ist doch Harvard-Architektur.

Wie auch immer, auch bei der Harvard-Architektur der AVRs stellt sich das gleiche Problem, wenn variable Codeteile von einem Bootloader in den Flash geladen werden.

Und die Lösung ist, Tätä: Relozierung. D.h.: der Bootcode muß schlicht ein wenig intelligenter werden und die Codedaten müssen in ein relozierbares Format gebracht werden, damit der Bootloader sie zur Laufzeit entsprechend der Zieladresse relozieren kann.

Was du hier mit "relozierbar" bezeichnest, meint eigentlich "position independent". Das ist (im engen Sinne) Code, der ohne jede Änderung ab jeder beliebigen Adresse im Zielsystem lauffähig ist. Es ist nämlich eigentlich so: Jeder Code ist relozierbar. Das besondere bei "position independent"-Code ist, daß hier für eine Relozierung nichts an den Codedaten geändert werden muß.

Für jeden anderen Code gilt: Relozierung ist möglich, wenn der Code in einen Container verpackt wird, der das unterstützt. Dazu gehören dann zwei Seiten, die beide wissen müssen, wie der Container aufgebaut ist: Der Linker auf der einen Seite muß dafür sorgen, daß die zur Relozierung nötigen Infos mit im Container landen und der Loader auf der anderen Seite muß sie zur Laufzeit benutzen, um den Code für das Ziel zu relozieren.

Übliche Containerformate dieser Art sind etwa ELF oder PE. Beide sind aber für typische µC-Anwendungen eigentlich viel zu aufgeblasen, weil sie Unmassen weiterer Sachen in den Container packen können, die im µC-Bereich völlig irrelavant sind. Was die "Hochsprachen"-Entwickler in aller Welt allerdings kaum davon abhält, sie trotzdem dafür zu benutzen, was wiederum Bootloader mit einem Umfang nach sich zieht, die nicht selten die Größenordnung der eigentlichen Anwendung übertreffen...

Nein, es war ein C167, der ist 'von Neumann'.

Und genau das habe ich gebraucht, weil ich ihn ja selbst zur Laufzeit aus dem Flash in's RAM kopiert und dann aufgerufen habe.

I stand corrected.

Ich hatte halt nur die Adresse der Routine und eine grobe Abschätzung ihrer Länge mithilfe mehrerer Labels. Das wurde dann per memcpy von A nach B kopiert und per (B)() aufgerufen. B hat dann den (das?) Flash geflasht und den vorher über TCP/IP in den RAM geschobenen neuen Programmcode in's Flash geschrieben (und ist hinterher wieder da hinein gesprungen).

Amen.

Markus

Hallo Michael!

Ja, das ändert nichts.

Gruß Thorsten

Hallo Joerg!

Wo steht denn -c? Im Makefile finde ich nichts passendes?

override CFLAGS = -g -O1 -Wall -Wstrict-prototypes

-Wa,-ahlms=$(

Thorsten Ostermann schrieb:

Dann nutzt Dein Makefile offenbar das implizite Wissen von Make, dass man mit -c vom Sourcecode zum Objectfile kommt. Lass die problematische Datei doch mal manuell zu einem Assemblerfile compilieren:

avr-gcc -g -O1 -Wall -Wstrict-prototypes -Wa,-ahlms=main.lst

-mmcu=atmega128 -S -o main.s main.c

CU Christian

--
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net
WWW: http://www.chzsoft.com.ar/
PGP/GnuPG-Key-ID: 0x6DA025CA

Christian Zietz schrieb:

Wahrscheinlich würde einfach "make main.s" genügen. Wenn das make implizit weiß, dass man mit -c von .c nach .o kommt, dann weiß es sehr wahrscheinlich auch, dass man mit -S von .c nach .s kommt.

--
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

Joerg Wunsch schrieb:

Vermutlich nicht. Ich habe gerade keine Zeit, das auszuprobieren, aber diese Regel steht zumindest nicht im Manual von GNU Make:

CU Christian

--
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net
WWW: http://www.chzsoft.com.ar/
PGP/GnuPG-Key-ID: 0x6DA025CA