GCC AVR ASM max. Anzahl Zeichen pro Label?

Adib schrieb:
> welche Beschränkung hat eigentlich der GCC ASM in Bezug auf die Länge
> der Sprungmarken?

Meines Wissens keine.

Da es aber ein AT&T-style assembler ist (Unix-Ursprung), lohnt es
sich, möglichst viele local labels zu nutzen, das spart unsinniges
Aufblähen mit benannten labels:

1

     clr  r17

2

     ldi  r16, 8

3

1:   ld   r24, Z+

4

     or   r24, r24

5

     breq 2f

6

     xor  r17, r24

7

2:   dec  r16

8

     brne 1b

63 significant initial characters in an internal identifier or a macro
name (each universal character name or extended source character is
considered a single character)
31 significant initial characters in an external identifier

Peter D. schrieb:
> 63 significant initial characters […]

Jetzt müsstest du noch die Quelle angeben.

Das da klingt mir eher wie copy&paste des C-Standards denn wie ein
Dokument, welches tatsächlich die Implementierung beschreibt.

Jörg W. schrieb:
> Das da klingt mir eher wie copy&paste des C-Standards

Stimmt.
Ich gehe mal davon aus, daß der Assembler die gleichen Tools/Linker 
nimmt, wie der Compiler.

Peter D. schrieb:
> Jörg W. schrieb:
>> Das da klingt mir eher wie copy&paste des C-Standards
>
> Stimmt.

Dann beschreibt es aber nicht den Ist-Zustand, sondern lediglich die
Minimalanforderungen.

> Ich gehe mal davon aus, daß der Assembler die gleichen Tools/Linker
> nimmt, wie der Compiler.

Den gleichen Linker: ja, aber das Parsen des Quelltextes ist komplett
separat.  Das entscheidet aber über interne Labels.

Der Assembler muss gemangelte C++-Symbole beherrschen, und da reichen 63
Zeichen nie und nimmer.

Folgendes Programm übersetzt der Assembler anstandslos:

1

a...a: ret

"a...a" steht dabei für 2**28 = 268435456 mal das Zeichen "a".

Dafür benötigt der Assembler aber etwa 380 s. Das Label findet sich
anschließend in voller Länge als Symbol in der Objektdatei wieder.
Das reicht normalerweise sogar für C++-Programme :)

Noch längere Labels habe ich nicht ausprobiert, da der Rechenaufwand
quadratisch mit der Labellänge zu wachsen scheint. Interessant wäre
allenfalls, ob vielleicht beim Überschreiten von 2**32 Zeichen Probleme
auftreten.

Kaj schrieb:
> Yalu X. schrieb:
>> "a...a" steht dabei für 2**28
> Kannst du jetzt auch noch erklären wo diese 2^28 herkommt? o_O

Wie gesagt, das ist nicht das längstmögliche Label, sondern nur das
längste, das ich ausprobiert habe. Dazu habe ich ein kleines Skript
geschrieben, das mit dem Label "a" beginnt und dieses in jedem Schritt
mit sich selbst konkateniert, so dass alle die getesteten Längen alle
Zweierpotenzen sind. Nach dem Test der Länge 2**28 habe ich das Skript
abgebrochen.

Yalu X. schrieb:
> Wie gesagt, das ist nicht das längstmögliche Label, sondern nur das
> längste, das ich ausprobiert habe.

Mal ein Hobbyprogrammierereinwand :-)
Kann der Assembler dann auch noch das Label 2hoch28'a' von 2hoch27'a' 
unterscheiden? Also wird auch die volle Länge an den Linker 
weitergereicht?

Edit: ... bzw. weitergereicht wird's sicher, aber frisst der Linker das?

Hab's mal getestet. Die folgenden beiden Quellcodefiles werden einzeln
assembliert und anschließend zusammengelinkt:

main.s:

1

  rcall a…a1

2

  rcall a…a2

sub.s:

1

  .global a…a1

2

a…a1: ret

3

4

  .global a…a2

5

a…a2: ret

Die beiden verwendeten Labels enthalten jeweils n-mal das Zeichen "a",
gefolgt von einer "1" bzw. einer "2". Ich konnte das Ganze allerdings
nur bis n=2**27 testen, da bei n=2**28 das Bash-Skript zur Erstellung
der Dateien aussteigt.

Der gelinkte Code war jedenfalls korrekt, d.h. die 2**27+1 Zeichen der
Labels sind tatsächlich alle signifikant:

1

   0:   01 d0           rcall   .+2             ;  0x4

2

   2:   01 d0           rcall   .+2             ;  0x6

3

   4:   08 95           ret

4

   6:   08 95           ret

Yalu X. schrieb:
> Hab's mal getestet.

Danke.