Forum: Mikrocontroller und Digitale Elektronik syntax error, unexpected INTEGER


von F. P. (pl504)


Lesenswert?

Kann mir jemand weiterhelfen?
Habe versucht, den Code von 
http://www.mikrocontroller.net/articles/AVR_Arithmetik#Rundung_zum_N.C3.A4chsten 
zu implementieren, aber leider meckert der Compiler bei der Zeile:
1
1:  brcs  2f
: error: syntax error, unexpected INTEGER

So ganz verstehe ich die Zeile auch nicht. "2f" müßte nach meinem 
Verständnis für eine Adresse stehen, aber die gibt es ja nirgends 
(höchstens "2", aber was soll dann das "f" dahinter?). Weiter unten gibt 
es noch
1
rjmp  1b
, wofür steht das "b"?

von Chris B. (dekatz)


Lesenswert?

Ich kenne das nur vom MICROCHIP ASM30 (Local labels):

2f steht für Forward to label 2:
1b steht für Backward to label 1:

Anhand der kurzen Codefragmente vermute ich, das es sich auch um "local 
labels" handelt.
WARUM der Compiler/Assembler das nicht kennt kann ich nicht sagen, da 
ich mit AVR-Tools nichts zu tun habe.

von F. P. (pl504)


Lesenswert?

OK, dann scheint das am alten Compiler zu liegen. Ich versuch das mal 
mit einem anderen...
Danke für Deine Erklärungen.

von c-hater (Gast)


Lesenswert?

F. P. schrieb:

>
1
1:  brcs  2f
: error: syntax error, unexpected INTEGER
>
> So ganz verstehe ich die Zeile auch nicht. "2f" müßte nach meinem
> Verständnis für eine Adresse stehen, aber die gibt es ja nirgends
> (höchstens "2", aber was soll dann das "f" dahinter?). Weiter unten gibt
> es noch
1
rjmp  1b
, wofür steht das "b"?

Tja, so sieht Assemblercode aus, wenn GCC-Fetischisten die natürliche 
Schönheit der Assemblersprache verhunzen...

Die führende Zahl stellt offensichtlich tatsächlich das Label dar, zu 
dem jeweils gesprungen werden muß, nur so ergibt der Code einen Sinn.

Der angehängte Buchstabe dürfte irgendeine Steuerung für die Berechnung 
des Displacements darstellen, welches letztlich im Opcode landen muß.

Eine völlig kranke Konstruktion. GCC halt.

von spess53 (Gast)


Lesenswert?

Hi

>Anhand der kurzen Codefragmente vermute ich, das es sich auch um "local
>labels" handelt.
>WARUM der Compiler/Assembler das nicht kennt kann ich nicht sagen, da
>ich mit AVR-Tools nichts zu tun habe.

Mit lokalen Labels hat das nichts zu tun.
Der Code stammt nicht vom 'normalen' Assembler des AVR-Studios sondern, 
wenn ich mich nicht irre, von dem des GCC. Die sind nicht ganz 
kompatibel. Beim Assembler des AVR-Studios darf ein Label nicht mit 
einer Zahl anfangen. Deshalb gibt es eine Fehlermeldung. Den Syntax 'f' 
und 'b' für forward und backward kennt der AVR-Assembler auch nicht.

MfG Spess

von F. P. (pl504)


Lesenswert?

Also könnte ich die Sprungmarken einfach umbenennen, was keine negative 
Auswirkung auf den Code hätte (Geschwindigkeit)?

von Chris B. (dekatz)


Lesenswert?

Lokale labels in dieser oder ähnlicher Schreibweise gab es schon in der 
Computersteinzeit bzw. vor der Entstehung von "GCC-Fetischisten".

Ich bin mir jetzt nicht sicher ob es nicht auch beim MASM 6.xx (oder 
später) so etwas gab, mir ist es auf jedenfall schon vor längerer Zeit 
mal untergekommen (kann aber auch eine andere CPU gewesen sein).

Ich ziehe diese Schreibweise jedenfalls den dämlichen Formulierunge al 
la:
bra $-4
jmp $+6
etc. vor.
Diese stammen (wenn nicht von einem Compiler erzeugt - wie von <spess53> 
erklärt) dann von Assembler-Fetischisten die unbeding beweisen 
woll(t)en, das sie schon bis 4, 6 oder sonstwieweit zählen können.

von spess53 (Gast)


Lesenswert?

Hi

>Also könnte ich die Sprungmarken einfach umbenennen,

Ja.

>was keine negative Auswirkung auf den Code hätte (Geschwindigkeit)?

Nein.

MfG Spess

von Yalu X. (yalu) (Moderator)


Lesenswert?

Wie Chris schon geschrieben hat, sind das so genannte "local Labels".
Sie werden u.a. auch vom GNU-Assembler unterstützt:

  http://sourceware.org/binutils/docs-2.23.1/as/Symbol-Names.html#Symbol-Names

Lokale Labels sind sehr praktisch für kurze Sprünge, da man sich dafür
nicht jedesmal einen neuen Namen ausdenken muss. Durch das an die Nummer
angehängte 'f' oder 'b' erkennt nicht nur der Assembler, sonder auch der
Leser, in welcher Richtung er nach dem Sprungziel suchen muss. Die
Programme werden dadurch leichter schreib- und lesbar.

F. P. schrieb:
> Also könnte ich die Sprungmarken einfach umbenennen, was keine negative
> Auswirkung auf den Code hätte (Geschwindigkeit)?

Natürlich. In der oben verlinkten Dokumentation ist auch ein Beispiel
dafür angegeben. Du musst halt beachten, dass die Namen (Nummern) der
lokale Labels mehrfach im Code vorkommen können und du deswegen jedem
einen eigenen (eindeutigen) Namen verpassen musst.

c-hater schrieb:
> Tja, so sieht Assemblercode aus, wenn GCC-Fetischisten die natürliche
> Schönheit der Assemblersprache verhunzen...

Das hat mit GCC nichts, aber auch gar nichts zu tun. Zum einen ist der
GNU-Assembler nicht Bestandteil von GCC, zum anderen verwendet der GCC
überhaupt keine lokalen Labels. Diese sind primär für handgeschriebene
Assemblerprogramme gedacht. Aber da du offensichtlich nicht nur mit C,
sondern mit der Computerprogrammierung generell auf Kriegsfuß stehst,
ist dir das wohl entgangen ;-)

von c-hater (Gast)


Lesenswert?

Chris B. schrieb:

> Lokale labels in dieser oder ähnlicher Schreibweise gab es schon in der
> Computersteinzeit bzw. vor der Entstehung von "GCC-Fetischisten".

Huch? Es ging überhaupt nicht um die Schreibweise lokaler Labels, 
sondern um die Schreibweise PC-relativer Sprungziele. Aber soweit stehen 
GCC-Fetischisten wahrscheinlich nicht im Stoff, um solche Feinheiten 
noch unterscheiden zu können...

> Ich bin mir jetzt nicht sicher ob es nicht auch beim MASM 6.xx (oder
> später) so etwas gab, mir ist es auf jedenfall schon vor längerer Zeit
> mal untergekommen (kann aber auch eine andere CPU gewesen sein).

Ja, es gab tatsächlich in der Steinzeit der Computerei mal Assembler, 
die bei Sprungzielen (insbesondere PC-relativen) keine symbolischen 
Adressen als Ziel akzeptiert haben. Aber das war wohl zuletzt vor so 
ungefähr 30 Jahren der Fall...

Der GCC hingegen ist heute so schlecht, daß er ähnliche Hilfe braucht. 
Ähnlich deshalb, weil offensichtlich nicht das Ausrechnen des 
Displacements das Problem ist, denn er akzeptiert ja die symbolische 
Zieladresse, braucht aber aus irgendeinem völlig unerfindlichen Grund 
die Angabe, ob das Label aufwärts oder abwärts vom aktuellen PC liegt. 
Wer zum Teufel soll das denn besser wissen als der verfickte Compiler 
selbst? Der assoziiert doch die Symbole mit den Adressen...

Indiskutabler Vollschrott. Von Idioten für Idioten.

von Knigge (Gast)


Lesenswert?

c-hater schrieb:
>
> Indiskutabler Vollschrott. Von Idioten für Idioten.

Ups, hat jemand deinen Stein hochgehoben?
Wie kommst du mit dem Sonnenlicht klar?

von Davis (Gast)


Lesenswert?

> Indiskutabler Vollschrott. Von Idioten für Idioten.

Dann wünsche ich dir noch viel Erfolg mit dem GCC.

von c-hater (Gast)


Lesenswert?

Yalu X. schrieb:

> Lokale Labels sind sehr praktisch für kurze Sprünge, da man sich dafür
> nicht jedesmal einen neuen Namen ausdenken muss.
[...]
> Programme werden dadurch leichter schreib- und lesbar.

Ah ja. Im konkreten Fall ist also z.B. "1:" wirklich wesentlich leichter 
zu lesen, als wenn da ganz kompliziert gestanden hätte "iteration_loop:" 
und bei der entsprechenden Verweigung "rjmp 1b" ist natürlich auch 
wesentlich einfacher zu lesen als "rjmp iteration_loop". Also, es ist 
wirklich interessant, was die GCC-Fetischisten da so an Argumenten 
bringen...

Warum zum Teufel benennt ihr eure verschissenen C-Funktionen dann 
eigentlich? Die konnte man nach der gleichen Logik, die du hier bringst, 
doch auch einfach durchnummerieren.

Also diese C-Freaks schrecken argumentativ echt vor nix zurück, nichtmal 
davor, sich nach den Gesetzen der Logik selbst den Wind aus den Segeln 
zu nehmen. Aber scheinbar können sie soweit nicht denken...

von Knigge (Gast)


Lesenswert?

c-hater schrieb:

> Warum zum Teufel benennt ihr eure verschissenen C-Funktionen dann
> eigentlich?

Kann bitte jemand den Stein wieder hinlegen, er kommt mit dem 
Sonnenlicht nicht klar!

von Karl H. (kbuchegg)


Lesenswert?

c-hater

Du hast nichts kapiert.
Es geht um Labels, die man per Namen relativ ansprechen kann.
Das erste Label unmittelbar VOR dem Jump.
Oder das zweite Label unmittelbar NACH dem Sprung.
Mit PC-relativer Adressierung hat das genau gar nichts zu tun, sondern 
schon eher mit der Verwendung von Labels in Makros, die so gestaltet 
sein müssen, dass die Makroexpansion auch dann noch zum richtigen Label 
innerhalb des Makros springt, wenn das Makro mehrmals instanziiert wird. 
Ohne eine derartige Möglichkeit würde der Assembler dann mehrmals 
dasselbe Label vorfinden. Und ja, die Verwendung dieser Art der 
Adressierung darf man auch ausserhalb von Assembler-Makros benutzen.

Und mit GCC hat das alles genau gar nichts zu tun, weil es von GNU auch 
einen Universalassembler gibt. Und genau um letzteren geht es hier.

Was programmierst du eigentlich? C magst du nicht. Mit Assembler kennst 
du dich nicht aus, bzw. bist nicht in der Lage die Möglichkeiten zu 
erkennen, die dir eine bestimmte Syntax eröffnet. Welche Sprache benutzt 
du also?

von Knigge (Gast)


Lesenswert?

Karl Heinz Buchegger schrieb:

> Was programmierst du eigentlich? C magst du nicht. Mit Assembler kennst
> du dich nicht aus, bzw. bist nicht in der Lage die Möglichkeiten zu
> erkennen, die dir eine bestimmte Syntax eröffnet. Welche Sprache benutzt
> du also?

Hat er doch schon hinreichend dargestellt: Gossensprache! ;-)

von Karl H. (kbuchegg)


Lesenswert?

Karl Heinz Buchegger schrieb:

> Das erste Label unmittelbar VOR dem Jump.
> Oder das zweite Label unmittelbar NACH dem Sprung.

Das stimmt nicht ganz. Der in GAS implementierte Mechanismus 
funktioniert ein wenig anders.
Hier ist die Doku dazu
http://sourceware.org/binutils/docs-2.21/as/Symbol-Names.html

Ändert aber nichts am grundsätzlichen Sachverhalt. c-hater, du solltest 
mal ein wenig über deinen Tellerrand blicken. Du könntest dabei noch was 
lernen.


> Ah ja. Im konkreten Fall ist also z.B. "1:" wirklich wesentlich
> leichter zu lesen, als wenn da ganz kompliziert gestanden hätte
> "iteration_loop:"

Es ist dann einfacher zu handhaben, wenn es neben der Wurzel-Routine 
auch noch ein LCD-Paket gibt, in dem ebenfalls eine "iteration_loop" 
vorkommt, oder eine Divisionsroutine, in der es eine "iteration_loop" 
gibt, oder ...
Oder stehst du drauf, wenn du in seitenweise Assembler-Source Code beim 
Zusammenkopieren von Codebestandteilen aus einem Code-Pool auch noch 
Name-Clashes der Label händisch auflösen musst?

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.