www.mikrocontroller.net

Forum: Compiler & IDEs avr-gcc: Wie Daten alignen?


Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

gibt es eine Möglichkeit, in avr-gcc Daten, die im Flash stehen, auf 
gerade Adressen zu alignen?

Die Daten sollen nach Section .progmem.data, d.h. ich würde gerne so 
etwas machen:
const char Data[] __attribute__((aligned(1))) PROGMEM = 
{
   ...
};

Das Attribut wird angewarnt und ignoriert.

Ein
asm (".align 1");

funktioniert auch nicht, weil der Compiler die Reihenfolge nicht einhält
und das .align nicht an der richtigen Stelle ausgegeben wird.
Ein -fno-reorder-functions hilft auch net.

Weiß jemand, wie das geht?

Danke für Tipps!

Johann

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

Bewertung
0 lesenswert
nicht lesenswert
Wofür brauchst du das denn?  Normalerweise fügt der Linkerscript
doch ein Füllbyte nach dem .progmem.data ein.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch wrote:
> Wofür brauchst du das denn?

Erstens interessiert mich wie das geht. In meiner judendlichen 
Baläugigkeit dachte ich, sowas wäre per __attribute__((align(.))) 
machbar.
Das ist doch maschinenunabhäbgig? Aber avr-gcc emittiert kein .align ins 
.s, weder die 4.x noch die 3.x.

Zweitens wäre das ganz hübsch für ne bestimmte Optimierung, weil dann an 
Bit 0 der Adresse zu sehen ist, ob von einem geraden oder ungeraden 
Offset aus dem betreffenden Objekt gelesen wird, ohne den Index selbst 
mitzuschleifen.

Im betreffenden Falle hat ein Datensatz 9 Bit, mit dem Alignment-Wissen 
hätte er nur noch 8 Bit. Das Objekt würde dann 43% (7/16) kleiner 
ausfallen.

> Normalerweise fügt der Linkerscript
> doch ein Füllbyte nach dem .progmem.data ein.

Das alignt doch nur die Section, nicht die Objekte darin?
Ich brauch es nur für dedizierte Objekte.

Durch Rumprobieren hab ich folgendes gefunden:
SECTIONS 
{
    .text : 
    {
        *(.wall) 
        . = ALIGN(2);
        WALL = .;
    }  > text
}

und im C-File:
const uint8_t WALL[] __attribute__((section(".wall"))) =
{
   ...
};

Kannst du das bestätigen? ld ist so ne Sache, nach der Doc wären mir 
auch 1000 andere Formulierungen plausibel...

Wieso landet das in _edata?

Ausserdem verstehe ich das map-File nicht:
*(.fini0)
                0x00003094                _etext = .
 *(.wall)
 .wall          0x00003094       0x19 snake.o
                0x000030ae                . = ALIGN (0x2)
 *fill*         0x000030ad        0x1 00
                0x000030ae                WALL = .

Wieso steht hier WALL bei 30ae und nicht ab 3094?
Es ist das einzige Objekt in .wall.

Im .lst stehen diese Daten dann dann doch ab 3094. Da ist doch noch was 
faul?

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

Bewertung
0 lesenswert
nicht lesenswert
Johann L. wrote:

> Erstens interessiert mich wie das geht. In meiner judendlichen
> Baläugigkeit dachte ich, sowas wäre per __attribute__((align(.)))
> machbar.

Du meinst __attribute__((aligned(2)))?

Das bringt bei mir eine Warnung, die auch letztlich erklärt, warum
es nicht funktioniert:
foo.c:5: warning: alignment of 'z' is greater than maximum object file alignment.  Using 1

> Kannst du das bestätigen?

Hab gerade keine rechte Zeit, mich da rein zu vertiefen.

> Wieso steht hier WALL bei 30ae und nicht ab 3094?

Ich habe immer den Eindruck, dass GNU ld linker maps zu den am besten
verschlüsselten Dateien gehören. :-/

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann L. wrote:
> gibt es eine Möglichkeit, in avr-gcc Daten, die im Flash stehen, auf
> gerade Adressen zu alignen?

Wozu?

Der LPM-Befehl kann doch nur 8-bittig lesen, also ist das aufm AVR 
vollkommen wurscht, der Code- und Zeitverbrauch ändert sich nicht.


Peter

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger wrote:

> Wozu?

Hatte ich ober erkläutert...

Jörg Wunsch wrote:
> Du meinst __attribute__((aligned(2)))?

Ja :-)

> Das bringt bei mir eine Warnung, die auch letztlich erklärt, warum
> es nicht funktioniert:
>
>
> foo.c:5: warning: alignment of 'z' is greater than maximum object file
> alignment.  Using 1
> 

Versteh ich net. Funktionen werden doch auch aligned und landen in text. 
Woher weiß der Linker das eigentlich? Von .type @funktion oder @object?

>> Kannst du das bestätigen?
>
> Hab gerade keine rechte Zeit, mich da rein zu vertiefen.

Ok, sorry. Ich dachte du weisst das ausm Stegreif ;-)

> Ich habe immer den Eindruck, dass GNU ld linker maps zu den am besten
> verschlüsselten Dateien gehören. :-/

Yupp, dito für ld-Scrips. Nur TeX und Intercal sind besser.

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

Bewertung
0 lesenswert
nicht lesenswert
Johann L. wrote:

> Versteh ich net. Funktionen werden doch auch aligned und landen in text.
> Woher weiß der Linker das eigentlich?

Noch schlimmer: der Compiler weiß das schon!  Das war eine reine
Compilerwarnung, ich habe mit -S direkt Assemblercode generiert.

Die Ausrichtung der Befehle ist automatisch, da alle Befehle in der
Länge durch 2 teilbar sind.  Lediglich nach .progmem ist ein separates
ALIGN notwendig (da es ja eine ungerade Anzahl von Bytes sein können),
das steht im Linkerscript:
...
    *(.vectors)
    KEEP(*(.vectors))
    /* For data that needs to reside in the lower 64k of progmem.  */
    *(.progmem.gcc*)
    *(.progmem*)
    . = ALIGN(2);
     __trampolines_start = . ;
...

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok hab's jetzt so, damit ist alles wie gewünscht, und die Info im .map 
ist konsistent mit dem .hex :-)
SECTIONS 
{
    .text : 
    {
        . = ALIGN(2); 
        *(.wall) 
        . = ALIGN(2); 
    }  > text
}

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.