State Machine Compiler für 8-bit AVRs?

Am 21.09.2019 um 11:29 schrieb Andreas Weber:

Meine Lexer und Parser habe ich bisher immer selbst geschrieben, das ist

und wenn sich beide Seiten an diese halten, und sinnvolle Trennzeichen zwischen zwei Werten und Records einstreuen, wo sollten dann Probleme herkommen?

DoDi

Am 21.09.19 um 12:26 schrieb Hans-Peter Diettrich:

Dann hast du bis jetzt vielleicht keine komplizierte Grammatik gehabt.

bestehendes Protokoll ran musst, kann man sich das nicht mehr aussuchen.

-- Andy

Am 21.09.19 um 19:09 schrieb Andreas Weber:

Eine komplizierte Grammatik ist in jedem Fall kompliziert, egal welche Werkzeuge man nutzt.

Wenn man das Prinzip verstanden hat, ist der Aufwand, um eine formal

Parser gleich selbst zu schreiben, nicht sooo unterschiedlich. Das gilt umso mehr dann, wenn der vom Generator erzeugte Codestil nicht recht in die verwendete Umgebung passt und man auch noch eine

Hergen

Am 21.09.2019 um 19:09 schrieb Andreas Weber:

Auch bei komplexeren Grammatiken ist das kein Hexenwerk.

Fehlerbehandlung haben. Wenn also irgendwo ein Trennzeichen verschluckt

sowas wie "mit dem eigenen Parser die Paketierung zerlegen, und die Paket-Payloads dann mit was generiertem").

Stefan

Hallo Hergen,

Am 21.09.19 um 20:37 schrieb Hergen Lehmann:

einzusetzen?

"Verwende doch Assembler, mach BRAUCHT keinen C Compiler. Das geht auch alles so. Die libc braucht man nicht, kann man auch in Assembler

einen wirklich, wirklich guten Grund.

mir den Zustandsautomaten visualisieren lassen (graphviz dot) was die Entwicklung deutlich vereinfacht und gleich noch als Dokumentation

Klar. In dem von mir angesprochenen Fall integriert sich das aber super in avr-gcc und AVR libc.

git/mercurial/subversion gar nicht braucht, weil man ja die Order einfach wegkopieren und umbenennen kann.

Am 21.09.2019 um 19:09 schrieb Andreas Weber:

sich ein Lexer von Hand leicht erzeugen. Bei wirklich komplizierten

Parser funktioniert und ihn entsprechend auch selbst schreiben kann.

DoDi

Vermutlich weil es denen zu komplex ist. :-)

Ich hab fuer solche Anwendungen auf Microcontrollern auch schon flex genutzt und wuerde es jederzeit wieder machen.

Vorteile: Sehr flexibel, es ist eine kleinigkeit da mal eben einen neues Kommando hinzuzufuegen.

Weil die nutzung so einfach ist, wenn man einmal damit umgehen kann, nutzt man es auch fuer Kleinigkeiten (z.B Debuginterface) wo man sonst eher denken wuerde: "Och, noe, dafuer bin ich jetzt zu faul"

Nachteile: Erzeugt ziemlich grossen C-Source. Das bekommt man von Hand bestimmt effizienter hin. Allerdings ist das bei den fetten Flash heutiger Controller kein Problem.

Nicht zwangslaeufig weil die sich ja auch mit dem verwendeten Generator auskennen muessen und ihn auch haben muessen.

Olaf

Am 21.09.19 um 11:29 schrieb Andreas Weber:

es auch gehen. Links/rechts-rekursiv mit 1 token look-ahead.

Da kommt auch nur eine Matrix raus und eine function, die inputs entgegennimmt und an den passenden Stellen die Aktionen triggert.

Automaten in Weinberger-Arrays. Weinberger-Arrays sind so was

(Aho, Weinberger, Kernighan). Die ganze UNIX/C-Truppe bei AT&T waren eigentlich Halbleiterleute und Digitaldesigner. Unix und C waren nur "Abfallprodukte".

Natuerlich! Die ganzen Programmierer sind nur Abfallprodukte der Hardwareentwicklung. Ich erzaehle denen das andauernd, aber sie wollen es einfach nicht akzeptieren. :)

Olaf

Kann ich dir nicht beantworten.

Beispielgrammatik teilen um zu illustrieren, wie du es im Moment (als

Eventuell kommen dann bessere Tipps.

Johannes

--

selben Hardware." -- Hans-Peter Diettrich in d.s.e.

geschrieben, der bei jeder minimalen Deviation im Codestil schon

Johannes

--

selben Hardware." -- Hans-Peter Diettrich in d.s.e.

Pascal-Compiler waren schon immer mit rekursivem Abstieg, und sogar der gcc war nur bis Version 3 yacc/bison-basiert und hat jetzt einen handgeschnitzten Parser.

Was ist foo *bar? Eine Variablen-Deklaration? Eine Multiplikation?

< >

Weil sie den C und C++ gemerged haben. Und C++ /hat/ keine

41000 Zeilen Code, mehr als ein Megabyte Quellcode. Das ist also etwas, das nicht mal eben so hinzuschreiben ist.

Insofern stehe ich zu meiner Aussage und widerspreche, dass es "praktische alle" eben mit handgeschnitzten Parsern machen. Im Gegenteil, wenn du mal suchst:

Ist Lex/Yacc-basiert

Nutzt ply

Nutzt jay

Nutzt Lex/Yacc

Nutzt rustpeg

Die Wenigsten schreiben also einen Lexer/Parser "von Hand". Noch

wiegesagt C++ der Grund).

Ich habe ja schon geschrieben, C ist kein LL(1). Keine mir bekannte (nicht-esoterische) Programmiersprache ist LL(1), so nebenbei.

Johannes

--

selben Hardware." -- Hans-Peter Diettrich in d.s.e.

Hatte ich seinerzeit als "ToPas" bei SourceForge reingestellt.

Dein Vermutungslevel ist als unbrauchbar notiert. Vielleicht informierst

Microsofts Header zu Visual C nicht standardardkonform sind, ein

Bis auf 1 Ausnahme ist C98 erstaunlicherweise LL(1), insgesamt also LL(2). Das Fehlen einer offiziellen LL-Grammatik sagt ja definitiv

DoDi

Sehr gut. Endlich lieferst du mal was. Ich habe mal meine VM angeworfen und dein Meisterwerk getestet:

Schon beim einfachen Gerumklicken fliegen einem "Access Violations" nur so um die Ohren, dass es kracht! Das fand ich MEGA witzig, weil du ja,

Bugs, die du angeblich durch Pascal vermeidest hast du offenbar so dutzendfach in deinem Programmchen drin, dass es UNBENUTZBAR wird. Sehr

Danach nochmal neugestartet, nichtdeterminsitisch fliegt einem eine Access Violation schon beim BLOSSEN START des Programms um die Ohren. Gacker! Ist das eine neue Form nichtdeterministischer Programmierung? Wow, ich bin echt beeindruckt.

- fehlerfrei

Okay, okay, das ist also die Messlatte. Siebenzeiler in C:

int foo(int y, ...) { int *x[12]; x[3] = x[9]; x[10] = *(&(*(x + 3))); "foo"; return 0; }

Einfach, oder? Das ist korrektes C. Na dann!

*TOMMELWIRBEL*

error translation_unit

Ach!

Das ist genau der Grund, warum man Parser Generatoren erfunden hat, weil es Leute gibt, denen aufgefallen ist, dass einem Menschen halt Cornercases oft durch die Lappen gehen. So wie dir.

Ja sorry aber "VisualBasic Discompiler" ist offenbar so ein unbrauchbarer Suchbegriff, dass Google gleich sagt: "Showing results for Visual Basic Decompiler"

Ich habe also keine Ahnung, worauf du hinaus willst. Du aber offenbar auch nicht, sondern willst ja wohl nur von deinem Turbofail ablenken.

Minuten gebraucht, den Testcase zu finden. Ich habe mehr Zeit damit verbracht, die Screenshots im Gimp zu editieren, als damit, dir

schwer ist.

C ist also kein LL(1), richtig.

Immerhin, muss man dir zu Gute halten, hast du ausnahmsweise was

Johannes

--

selben Hardware." -- Hans-Peter Diettrich in d.s.e.

Wenn hier einer den Oberlehrer macht, dann du. Und er muss dir auch nichts liefern, du hast nichts bei ihm gekauft.

Wirklich bewiesen hast du garnix. Du hast ein paar Exotencompiler

Compiler, die jeder hernimmt, wie gcc oder clang benutzen rekursiven Abstieg. Und der gcc frisst dein Beispiel in einer halben Millisekunde, problemlos, bis auf ein paar Bemerkungen, dass das Beispiel nix Sinnvolles macht.

wie das with-statement drinnen:

with record_variablenliste do begin ... end

keine rec.a und rec.b mehr, sondern einfach nur noch a und b.

nicht mehr. Bring das mal einem Parsergenerator nahe, wenn Variablen-

einem anderen Typ stehen.

In Jensen-Wirth's Pascal, User Manual and Report (insgesamt ein

drinnen.

Und das ganze UCSD-Pascalsystem konnte man auf einem Z80 mit AT-Floppies compilieren.

Gerhard

der von C), und dann in der Praxis halt schon bei simpelsten Beispielen voll auf die Nase fliegt, dann ist das ja schon ein interessantes Ergebnis.

Klar muss er nichts liefern, hat er ja bisher auch nie. Sobald es

Doch, dass der Parser, den DoDi geschrieben hat, eben nur (wie ich

du das bestreitest, kannst du es ja gerne selber ausprobieren.

Das sind keine Compiler, hast du die Links mal angesehen? Die erzeugen teilweise nur einen AST und sind Libraries.

Das ist *professionelle* Software. Mit hunderttausenden Personenstunden, die da reingeflossen sind, sowohl in clang als auch in gcc. Und ich habe

gibt (als Bonus gibt's bessere Diagnostics dazu). Insofern sind die als

wie schwierig es ist, Lexer/Parser von Hand zu schreiben.

Ohne Not schreibt *niemand* einen Parser von Hand, auch nicht gcc und clang. Und wenn man sich dazu entscheidet, ist das *weitaus* schwieriger, als einen Parsergenerator zu nehmen.

Recursive Descent ein ordentliches oder geeignetes Parsing-Verfahren ist. Ich sage lediglich, dass das Schreiben eines Parsers von Hand RICHTIG viel schwieriger ist, als einen Parsergenerator zu nehmen und

Zeit) braucht. Und bin extrem skeptisch wenn sich jemand hinstellt und sagt "das hab ich schon gemacht, war ganz einfach". Weil >40000 Zeilen

Ja, da gehe ich mit. Wenn es einen guten Grund gibt, klar, dann schreibt man sich seinen eigenen Parser. Damit kommen eine interessante Vorteile,

Johannes

--

selben Hardware." -- Hans-Peter Diettrich in d.s.e.

Am 23.09.2019 um 14:15 schrieb Gerhard Hoffmann:

Wobei ich mich frage, wie der C Preprozessor in einen generierten Parser eingebaut werden kann. Aber die Antwort kenne ich inzwischen schon,

DoDi

Aaaaaaaahahahahahaha!

Ja, klar. Wenn Dateien nicht gefunden werden, versucht er mal auf

Gott, du bist so armselig mit deinen dumm-dreisten Ausreden und

Neeeeeeeeein oh neeeeeeein, die allerschlimmste Strafe von allen. In deinem Filter zu "schmoren". Jetzt entgehen mir deine altklugen

Dass du nicht mal in der Lage bist, einen Newsreader zu bedienen,

Alles Liebe, Dein Johannes

--

selben Hardware." -- Hans-Peter Diettrich in d.s.e.