State Machine Compiler für 8-bit AVRs?

Hi Johannes,

Am 22.09.19 um 17:23 schrieb Johannes Bauer:

Ich bin bisher mit Ragel wirklich voll und ganz zufrieden und kann

wissen, was andere so verwenden. Dass das in so eine "angeregte

Reply to
Andreas Weber
Loading thread data ...

Ich warte ja auf das Gegenbeispiel, also: deinen C-Parser.

finden im Standard-Dokument unter "Annex A" sowie in Fragmenten in den einzelnen Kapiteln. Sie ist halt nur nicht LL(1).

zahlst du beim Debuggen drauf. Wo muss ich jetzt die Aktionen platzieren? Wie bekomme ich das Speicherleck-frei? Wie bekomme ich

geparsed. Mit einem generierten Parser muss man damit durch ein paar Ebenen Generat (yacc, lex) durch und dabei Annahmen treffen, wie der generierte Code sich benimmt.

Stefan

Reply to
Stefan Reuther

lange nicht, dass einen Parser mit Generator schreiben leicht ist.

Du kannst offenbar keine Standards lesen. Denn da steht ganz klar zuerstmal: Annex A (informative) -- muss ich dir jetzt den Unterschied

to be an aid to comprehension. It is not an exact statement of the language."

genau das habe ich geschrieben, keine ausdefinierte Grammatik).

Puh, naja, das ist jetzt Aussage gegen Aussage. Du findest das Schreiben

Das ist wohl richtig, eine ordentliche Grammatik zu schreiben ist auch

elendige Arbeit.

Einen Tod muss man sterben. Vermutlich ist dann wohl ausschlaggebend, womit man am meisten Erfahrung hat.

Johannes

--

selben Hardware." -- Hans-Peter Diettrich in d.s.e.
Reply to
Johannes Bauer

yacc ist nicht einfach. Wer gackert muss auch legen.

Das ist die Zusammenfassung der Fragmente. Nicht normativ, weil die normativen Teile nebst der semantischen Bedingungen in den anderen Kapiteln stehen, und weil dir niemand zusichert, in dem Anhang nichts vergessen zu haben.

Analyse" nicht sauber trennt. Jedem Praktiker ist das egal. Regeln wie "maximum munch" (also dass 'inti' ein Wort ist und nicht das gleiche wie 'int i') werden quasi immer in Prosa angegeben, nicht in der Grammatik.

Stefan

Reply to
Stefan Reuther

lediglich STARTET.

Ich bin mir extrem sicher, dass ich ein Programm hinkriege, dass nicht

Und einen Parser kann man auch in einer Programmiersprache schreiben,

Performance nicht kritisch ist.

Joa und ich habe produktiven, sicherheitskritsichen Kernelcode geschrieben, der jahrelang unterbrechungsfrei laufen muss. Da kann man sich keine Ressourcenleaks erlauben, nicht mal die Kleinsten.

Na du musst dich schon entscheiden. Entweder du unterstellst mir

bekommst eine entsprechend unfreundliche Antwort. Beides geht nicht.

Mag ja sein, trotzdem hast du einen INFORMATIVEN Teil als "Beleg"

ganz klar drin steht, dass es eben nicht den Sprachumfang abdeckt.

beliebiges Beispiel raus: "14.2. Names of template specializations". Eine popelige Grammatik, evtl 15 Zeilen lang. Gefolgt von 1 1/2 Seiten Prosa, die dann genau sagt wie die zu interpretieren ist.

Das ist keine formale Beschreibung einer Sprache. Das ist Prosa.

Eine formale Beschreibung, die man im idealfall direkt einem Parser vorlegen kann, also maschinenlesbar ist. C++ ist aber als Sprache so kompliziert, dass ich vermute, dass das wohl nicht (mehr?) machbar ist. Deswegen nutzt man eben viel Prosa und Beispiele, um zu verdeutlichen, was gemeint ist.

komplizierten Disambiguation Regeln. Die wirklich korrekt zu implementieren ist (auch aufgrund der mangelhaften Definition als

wieder bei Beispielen, die von einem Compiler gefressen werden und von einem anderen nicht.

gehabt mir trivialsten Mist wie

std::vector

std::vector

nur gruselig.

Johannes

--

selben Hardware." -- Hans-Peter Diettrich in d.s.e.
Reply to
Johannes Bauer

Am 27.09.2019 um 10:37 schrieb Johannes Bauer:

Das nennt sich - ich wiederhole mich - semantische Bedingungen. Von

usw.).

Diese Disambiguierungsregeln hat es zum Teil von C geerbt. 'a * b;' ist ein expression-statement oder eine Deklaration.

Das hat nichts mit schwammiger Disambiguierung zu tun, das ist ein ganz normaler "maximum munch" Lexer, der, wenn man ihm keinen Tipp gibt, '>>' als ein Token parsed.

Solche Effekte gibt es in vielen Sprachen. Pascal:

a := sqrt(.5);

(parsed nicht, weil '(.' als '[' interpretiert wird.)

Stefan

Reply to
Stefan Reuther

Am 27.09.2019 um 17:42 schrieb Stefan Reuther:

dabei sind, das "dangling else" wird auch weit einfacher in der

hat, nicht aber "short short". Ist eigentlich heutzutage auch "long

Sofern man Digraphen als Option eingeschaltet hat. Heutige Compiler

per Default. Delphi unterscheidet inzwischen sogar Kommentare in { } und

Schreibweise auskommentieren.

DoDi

Reply to
Hans-Peter Diettrich

Am 27.09.2019 um 21:22 schrieb Hans-Peter Diettrich:

"long signed long" ist das gleiche wie "long long".

24-Bit-Typen kennt (MPLAB C18). Was sollte denn "short short" sein? Bei

selten in freier Natur anzutreffen sein. Einfach, weil sich der

Zumindest die Turbo-Pascal-Compiler hatten keine mir bekannte

Das wiederum hatte Turbo Pascal auch.

Stefan

Reply to
Stefan Reuther

nutzloser ist die reine formale Grammatik. Weil dann kann ich

PROGRAM := chr(0..255)*

Ist aber halt super nutzlos, so eine Grammatik.

Schon klar. Aber es geht nicht darum, wieso der Parser das so parst, sondern was per Definition die *korrekte* Art des Parsens ist. Und, wenn

std::vector

Formal gesehen vor C++x ein Syntaxfehler. Ich glaube mich daran zu errinern, dass sowohl der MS C++-Compiler als auch der icc trotzdem das geparst haben, was "gemeint" war, und nur der gcc sich daran verschluckte. Und meiner Errinerung nach war gcc eben formal "korrekt". Aber das ist alles jetzt schon ewig her, bin mir in den Details nicht mehr ganz sicher.

Das verdeutlicht aber genau das Problem, das ich anspreche: Jemand, der einen Compiler schreibt, versucht das "richtige" zu machen, weil die

Schwanz mit dem Hund.

Johannes

--

selben Hardware." -- Hans-Peter Diettrich in d.s.e.
Reply to
Johannes Bauer

Am 28.09.2019 um 11:58 schrieb Stefan Reuther:

Das hat dann aber nichts mit einem C Standard zu tun, sondern ist eine compilerspezifische Erweiterung.

Deshalb schrieb ich ja "heutige" Compiler :-]

DoDi

Reply to
Hans-Peter Diettrich

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.