www.mikrocontroller.net

Forum: Compiler & IDEs Unterstützt AvrGCC den Atmega2561


Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi @ all,

Unterstützt das aktuelle WinAvr GCC Packet den Mega2561?

mfg Martin

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

Bewertung
0 lesenswert
nicht lesenswert
Martin wrote:

> Unterstützt das aktuelle WinAvr GCC Packet den Mega2561?

Der GCC benötigt einen Patch dafür, der aber im aktuellen WinAVR schon
drin ist.

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke

Autor: Der Techniker (_techniker_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sind eigendlich schon irgendwelche Bugs/Einschränkungen/ect. bekannt?

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

Bewertung
0 lesenswert
nicht lesenswert
Der Techniker wrote:

> Sind eigendlich schon irgendwelche Bugs/Einschränkungen/ect. bekannt?

Einschränkungen:

Nun ja, es ist halt eine halbherzige Portierung.  Klingt vielleicht
bisschen negativ (besonders angesichts der vielen und guten Arbeit,
die Björn Haase da reingesteckt hat).  Was es meint ist: der
ATmega256x (und wohl auch die größeren Xmegas, wenn sie denn mal da
sein werden) hat einen 24-bit-PC.  GCC kennt aber nur Zeiger der
Breite 16 oder 32 bit, und er muss auch alle Zeiger für einen
Zielprozessor gleich groß haben.  Um den ATmega256x zu bedienen, hätte
man mit normalen Mitteln also die Zeiger auf 32 bits ausdehnen müssen,
und dabei auch die Zeiger in den RAM vergrößert, obwohl der ja maximal
64 KiB hat.

Stattdessen hatte Marek Michalkiewicz seinerzeit eine Lösung
skizziert, die wohl als Vorbild irgendeinen anderen von GCC
unterstützten exotischen Prozessor hat, und Björn Haase hat diese
Lösung dann umgesetzt.  Man belässt die Zeigergröße dabei auf 16 bits
und unterteilt den Adressraum in Blöcke, die mit diesen Zeigern noch
adressierbar sind.  Da beim AVR die Codeadressen alle durch 2 geteilt
werden, lassen sich damit 128 KiB am Stück adressieren.  Zwischen
jedem der derart entstehenden Blöcke wird eine Sprungtabelle
angeordnet (Trampolin genannt), die als ,,Zwischenhüpf'' für alle
Sprünge dient, die die entsprechende Grenze überschreiten wollen.
Beim ATmega256x gibt es also genau eine davon, bei noch größeren AVRs
könnten es mehrere werden.

Dieser Ansatz funktioniert recht gut, auch wenn er auf den ersten
Blick sehr gewagt aussieht.  Das größte Risiko dieses Ansatzes ist
jedoch, dass der Linker Code über so ein Trampolin hinweg verteilen
könnte, den er besser nicht verteilen sollte.  Ein bekannter und
kritischer Fall stellen Sprungtabellen dar, wie sie z. B. vom Compiler
in großen case-Anweisungen erzeugt werden: da der Index den Offset in
die Sprungtabelle bildet, ist es natürlich tödlich, wenn der Linker
anschließend einen Teil der Sprungtabelle vor und den anderen hinter
dem Trampolin anordnet.  Leider hat der Compiler keine Ahnung, wohin
der Linker den Code mal platzieren wird, und der Linker weiß nicht,
dass der Compiler genau an dieser Stelle einen kritischen Block hat,
der unbedingt zusammenhängend bleiben muss.  Daher hatte Björn initial
im Assembler eine Warnung vorgesehen ("Expression is dangerous with
linker stubs.").  Der Nachteil davon war aber, dass sie in jeder auf
diese Weise erzeugten Sprungtabelle generiert worden ist und damit
eher Verwirrung gestiftet hat.  (Peter Dannegger bezeichnet sowas dann
wohl als ,schweren Bug'...)  Hinzu kommt, dass sie nur einen Teil der
möglichen fatalen Fälle überhaupt erkennen konnte, aber eine sichere
Erkennung der Gefahr gibt es gar nicht.  Daher hat Björn dann
zugestimmt, dass wir die Warnung abschalten. -- Die Gefahr bleibt aber
natürlich, wenn eine solche Tabelle genau über die 128-KiB-Grenze
hinweg aufgeteilt wird, dann kracht es, ohne dass die Tools diesen
Zustand derzeit feststellen und entsprechend darüber warnen könnten.

Das die einzige mir derzeit bekannte Falle im Zusammenhang mit dem
ATmega256x-Patch.

Allerdings hat der ATmega256x-Patch auch noch ,huckepack' einen Patch
mitgebracht, der main() zu einer normalen Funktion macht, wie es im
C-Standard eigentlich schon immer vorgesehen ist.  Dieser Patch bringt
uns zwar zurück zu standardgerechtem Verhalten, vergrößert aber
gleichzeitig das main(), da dort nun wie in jeder anderen Funktion
benutzte Register auf den Stack ,,gerettet'' werden etc. pp.  Abhilfe
dagegen ist es, main() als __attribute__((naked)) zu deklarieren und
eigentlich auch noch __attribute__((noreturn)), obwohl es verpflichtet
ist (vom Standard her), einen int zurückgeben zu können.  Eine
künftige Lösung sollte hier ein _attribute_ bieten, dass
gewissermaßen wie die Kombination der beiden genannten wirkt, aber den
Rückkehrwert trotzdem zulässt.  Das ist dann letztlich das, was beim
IAR-Compiler durch __c_task (vor main()) erreicht wird.

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jörg Wunsch

Interessanter Beitrag! Danke.

Ich habe keinen gepatchten GCC da, mit dem ich das schnell
ausprobieren könnte, deswegen folgende Frage: Wie werden
Funktionszeiger dargestellt? Da fehlt doch bei 16 Bit 1 Bit
Information, und Trampoline helfen hier sicher auch nicht weiter.

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

Bewertung
0 lesenswert
nicht lesenswert
> Wie werden
> Funktionszeiger dargestellt?

Gute Frage.  Nächste Frage?

Muss ich auch erst ausprobieren.  Aber prinzipiell könnte da die
Trampoline wohl auch helfen: der Zeiger ist 16 bits und zeigt dann
immer auf das Trampolin.

Autor: Der Techniker (_techniker_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du hierfür ein Codebeispiel, was zum Crash führen würde?
(evtl. kann ich es mir besser vorstellen, was du genau meinst)

Dabke!

Autor: Εrnst B✶ (ernst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
switch (somevariable) {

  case 1: /* Viel Code, der compiliert >= 128kb */
    break;
  case 2: /* anderer Code */
}

Wenn der Compiler die Switch-anweisung als Sprungtabelle implementiert, 
und nicht zu if ... else if ... else optimiert, schlägt der Aufruf von 
"anderer Code" bei somevariable==2 fehl.

Statt den 128kb im "case 1" reicht natürlich auch viel weniger code, 
wenn vor dem switch entsprechend mehr ist.

/Ernst

Autor: Der Techniker (_techniker_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Statt den 128kb im "case 1" reicht natürlich auch viel weniger code,
wenn vor dem switch entsprechend mehr ist."

D.h. bei >=128kb Code wird es ein Glücksspiel, was der Compiler draus 
macht?!? :-(

Betrifft das Problem auch Daten (z.B. Grafiken für ein Display), oder 
bleiben die davon unberührt?

Schöne Grüße

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

Bewertung
0 lesenswert
nicht lesenswert
Ernst Bachmann wrote:

>
> switch (somevariable) {
> 
>   case 1: /* Viel Code, der compiliert >= 128kb */
>     break;
>   case 2: /* anderer Code */
> }
> 

Nein, eher:
/* 127,9 KiB code hier */
...
  switch (somevariable) {
    case 1: ...
    case 2: ...
    /* viele case labels hier */
    case 13374: ...
  }

Nur bei vielen case labels wird der Compiler überhaupt in die
Versuchung kommen, eine Sprungtabelle anzulegen.  Der Code zwischen
den case labels ist nahezu unerheblich, der darf auch über die
128-KiB-Grenze hinweg gehen (das sortiert der Linker schon).  Der
einzig kritische Fall ist, dass die Sprungtabelle selbst vor der
128-KiB-Grenze (und damit dem nächsten Trampolin) beginnt, dann aber
vom Linker geteilt wird.  Kritisch daran ist, dass die
Tabellenberechnung halt nur die Anfangsadresse + Index rechnet und
nicht weiß, dass sie jetzt ab einem bestimmten Index die Größe des
Trampolins zusätzlich addieren müsste.

> Wenn der Compiler die Switch-anweisung als Sprungtabelle
> implementiert, und nicht zu if ... else if ... else optimiert, ...

"pessimiert", wolltest du hier schreiben.

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

Bewertung
0 lesenswert
nicht lesenswert
Der Techniker wrote:

> D.h. bei >=128kb Code wird es ein Glücksspiel, was der Compiler
> draus macht?!? :-(

Mehr oder weniger ja.  Du kannst die Sprungtabellen auch mit
-mno-tablejump komplett abschalten, allerdings kann das eben bei
großen switches zu mehr Code und schlechterer Performance (vor allem
zu ungleichmäßiger Laufzeit der einzelnen case labels) führen.

> Betrifft das Problem auch Daten (z.B. Grafiken für ein Display),
> oder bleiben die davon unberührt?

Die würde es natürlich genauso betreffen.  Allerdings können die
Standard-*_P()-Funktionen sowieso nur auf Daten unterhalb 64 KiB
zugreifen, für alles andere musst du dir die Zugriffe mit den
"far"-Versionen selbst organisieren.  Insofern wirst du dir deine
Daten in solchen Fällen wohl gleich manuell an bestimmten Stellen
anordnen.  Dann kannst du natürlich auch gleich oberhalb 128 KiB
anfangen (bzw. oberhalb des Trampolins, aber ich glaube, dass das
Ding nur existiert, wenn es auch wirklich benötigt wird).

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falls es für jemanden von Interesse ist: Ich habe inzwischen meinen
GCC 4.1.2 gepatcht und damit meine Frage von oben beantwortet:

> Wie werden Funktionszeiger dargestellt?

Jörgs Vermutung

> Aber prinzipiell könnte da die Trampoline wohl auch helfen: der
> Zeiger ist 16 bits und zeigt dann immer auf das Trampolin.

war natürlich richtig :-)

Es wird direkt nach der Interruptvektortabelle ein Trampolin angelegt,
das JMPs zu allen Funktionen enthält, die

- oberhalb der Wortadresse 64K (128 KBytes) liegen und

- deren Adresse im Programm einer Variablen zugewiesen oder an eine
  externe Funktion übergeben wird.

Der Funktionszeiger ist dann die Adresse des entsprechenden
JMP-Befehls im Trampolin und kann, da das Trampolin in den unteren 64K
liegt, mit 16 Bits dargestellt werden.

Der Aufruf erfolgt durch einen EICALL. Warum ein ICALL nicht
ausreicht, habe ich allerdings nicht ganz verstanden. Vielleicht
besteht die Möglichkeit, dass der Linker das Trampolin an eine Adresse
legt, die mit ICALL nicht erreichbar ist.

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

Bewertung
0 lesenswert
nicht lesenswert
Du kannst mal probieren, ob --relax beim Linker hilft.

Autor: Εrnst B✶ (ernst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da könnte man fast in Versuchung kommen, den alten AVR-Port im SDCC 
wieder zu aktivieren (Wurde damals eingestampft, weil der AVR-GCC besser 
war)
Der kommt aus der '51er Welt und hat deswegen eh schon x verschiedene 
Pointer-Arten (idata, xdata, code, generic...), die auch verschiedene 
Längen haben können (z.B. 3 bytes bei gptrs)
/Ernst

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

Bewertung
0 lesenswert
nicht lesenswert
Ernst Bachmann wrote:

> Da könnte man fast in Versuchung kommen, den alten AVR-Port im SDCC
> wieder zu aktivieren (Wurde damals eingestampft, weil der AVR-GCC besser
> war)

Du meinst, letzteres hätte sich mittlerweile geändert?

Ich denke, dass du selbst beim AVR-GCC mit -mno-tablejump allemal
besser bedient wärst...

Autor: Εrnst B✶ (ernst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch wrote:

> Du meinst, letzteres hätte sich mittlerweile geändert?

Nö, bestimmt nicht. Hat ja ewig niemand mehr was dran getan.
Aber von seiner "Entwicklungsgeschichte" her ist der SDCC halt besser an 
"Small devices" angepasst, mit Harvard-Architektur, Banking z.B. bei 
PICs, die verschiedenen Speicherarten bei '51ern etc.

/Ernst

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nochmal Thema Funktionszeiger:

>> Der Aufruf erfolgt durch einen EICALL.

Jörg Wunsch schrieb:

> Du kannst mal probieren, ob --relax beim Linker hilft.

Habe ich gerade: --relax ersetzt an vielen Stellen absolute Sprünge
(jmp, call) durch relative (rjmp, rcall), der eicall beim Aufruf eines
Funktionszeigers bleibt aber unverändert.

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.