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:
1 | SECTIONS
|
2 | {
|
3 | .text :
|
4 | {
|
5 | *(.wall)
|
6 | . = ALIGN(2);
|
7 | WALL = .;
|
8 | } > text
|
9 | }
|
und im C-File:
1 | const uint8_t WALL[] __attribute__((section(".wall"))) =
|
2 | {
|
3 | ...
|
4 | };
|
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:
1 | *(.fini0)
|
2 | 0x00003094 _etext = .
|
3 | *(.wall)
|
4 | .wall 0x00003094 0x19 snake.o
|
5 | 0x000030ae . = ALIGN (0x2)
|
6 | *fill* 0x000030ad 0x1 00
|
7 | 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?