Hallo, ich bin zur Zeit auf der Suche nach einem Parsergenerator und habe dabei das Gespann aus Flex und Bison entdeckt. Auf dem ersten Blick macht das genau den Eindruck, nach dem ich suche, jedoch habe ich ein Problem bei dem generierten Code. Der Parser soll später auf einem Mikrocontroller ausgeführt werden. Daher habe ich zwei Anforderungen an den Code. 1. Habe ich nicht alle Bibliotheken zur Verfügung die ich benötige um den generieren Code mit z.B. dem sdcc zu kompilieren. Allerdings, wenn ich die Fehlermeldungen an sehe, weiß ich auch nicht wozu der Code benötigt wird (es hängt an dem Datentyp FILE bzw. der stdio). Ich will einfach nur ein String rein kippen, und ein Syntaxbaum raus bekommen. Thats It. Ich will von keinem File lesen oder was auch immer das Ding macht oder auf die Standardausgabe schreiben. Gibt es Optionen um dem Gespann mitzuteilen, das es sich rein auf das Parsen fixieren soll? Oder gibt es vielleicht noch eine bessere Möglichkeit? 2. Es muss der Code so klein wie möglich sein. Auch wenn es gehen sollte, hab ich ein Interesse, das jeder unnötige Ballast raus fliegt. Ich hab auch ein Blick in die Doku gewagt, jedoch auf die Schnelle nichts brauchbares gefunden. Ich bedanke mich schonmal für die Hilfe Tobias
tobias schrieb: > Auch wenn es gehen sollte, hab ich ein Interesse, das jeder unnötige > Ballast raus fliegt. Dann würde ich dir statt bison auf jeden Fall den byacc anraten, der ist weniger komplex. FILE kannst du natürlich auch irgendwie emulieren, am Ende werden sie da nicht viel mehr als ein getc()/ungetc() machen, das müsste dann halt die Daten aus deinem String liefern.
bison braucht eine eigene yyerror()-Funktion für Fehlermeldungen. Für den flex Scanner-Input kannst/musst du ein eigenes YY_INPUT() Makro definieren. flex ECHO-Output ist ein Problem, ECHO benutzt einen FILE-Pointer. Da musst du etwas tiefer in die Details schauen wie man den los wird. Wenn es irgendwie geht (einfache lexikalische Tokens) würde ich sowieso den Scanner (alias Lexical Analyzer) von Hand schreiben, statt ihn mit flex zu generieren.
:
Bearbeitet durch User
Wenn der Mikrocontroller groß genug für "normales" C++ ist, kannst du dir ja mal boost::spirit anschauen. Oliver
Danke für die Antworten. > FILE kannst du natürlich auch irgendwie emulieren, am Ende werden sie > da nicht viel mehr als ein getc()/ungetc() machen, das müsste dann > halt die Daten aus deinem String liefern. Ich weiß nicht was da genau abläuft. Ich hab es auf dem PC kompiliert und hab dort ein String rein geschmissen und hab ein Syntaxbaum raus bekommen. Genau so wie ich das wollte. Das Emulieren ist eine Idee, jedoch erzeugt das wieder unnützen Code. Ich weiß auch nicht wie weit dieser Code dann beim Linken später wieder raus geschmissen werden kann. Ich könnte mir auch den Code zur Brust nehmen, und den Krempel via Hand raus schmeißen, doch führt das die komplette Idee mit dem automatisch generierten Code ins ad absurdum. > Wenn es irgendwie geht (einfache lexikalische Tokens) > würde ich sowieso den Scanner (alias Lexical Analyzer) von Hand > schreiben, statt ihn mit flex zu generieren. Ich bin da auch selbst noch am evaluieren. Was besonders komplexes wird es nicht werden, und eine lexikalische Analyse ist echt schnell mit der Hand geschrieben. Auch bin ich am überlegen, ob ich nicht auch einfach dann den Parser schreibe. Ich hab das zwar noch nie gemacht, aber ein LL(1) Parser scheint wohl auch kein Hexenwerk zu sein. Es wäre zumindest ein interessantes Projekt. > Wenn der Mikrocontroller groß genug für "normales" C++ ist, kannst du > dir ja mal boost::spirit anschauen. Der SDCC kann leider nur C, aber ich fürchte auch, das das viel zu oversized ist :(
Manche Implementierungen (POSIX) bieten fmemopen, vielleicht gib's das ja bei deinem Compiler oder du kannst was von einer bestehenden Implementierung abkupfern: https://github.com/lattera/glibc/blob/master/libio/fmemopen.c Aber wie bereits gesagt: Das was du parsen willst ist bestimmt nicht allzu kompliziert. Ein Parser-Generator ist da vermutlich wenig sinnvoll, z.b. wenn ein handgeschriebener Parser kürzer ist als Syntaxbeschreibung und Backend für den Parser-Generator...
:
Bearbeitet durch User
tobias schrieb: > Es muss der Code so klein wie möglich sein Der Code wird vielleicht nicht so sehr dein Problem sein... > um den generieren Code mit z.B. dem sdcc zu kompilieren. ...weil solche Tools weniger mit Code als vielmehr mit reichlich Datentabellen arbeiten (yacc/lex jedenfalls). Und wenn die nicht automatisch im ROM landen, beispielsweise weil Harvard-Architektur, dann kann es bei µCs eher im RAM als im ROM eng werden.
:
Bearbeitet durch User
A. K. schrieb: > Und wenn die nicht automatisch im ROM landen, beispielsweise weil > Harvard-Architektur, dann kann es bei µCs eher im RAM als im ROM eng > werden. Ich habe schon vor vielen Jahren mal ein Experiment gemacht, flex und byacc so zu hacken, dass sie für den AVR die Tabellen im Flash ablegen. Auf einem ATmega128 konnte ich damit einen simplen BASIC-Interpreter implementieren, allerdings hatte es nur mit externem RAM Sinn, da man ja auch das zu interpretierende Programm irgendwo ablegen können muss. Der Flash-Footprint lag so um die 12 KiB.
Schau dir mal GOLD Parsing System (http://goldparser.org/) an. Ist ein Parsergenerator, der Parser in vielen Sprachen erzeugen. Gibt´s auch eine Art IDE dazu, mit der man seine Grammatik entwickeln und testen kann.
Ups, vergessen: Eine Engine, die in Ansi C geschrieben wurde, gibt es auch. (http://goldparser.org/engine/1/c/index.htm) Ich habe bisher nur die Java, C++ und VB-Engines verwendet, kann also nicht sagen, wie gut die C-Engine funktioniert.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.