Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.sci.electronics > #264203 > unrolled thread

State Machine Compiler für 8-bit AVRs?

Back to article view | Back to de.sci.electronics

Contents

  State Machine Compiler für 8-bit AVRs? Andreas Weber <info@tech-chat.de> - 2019-09-21 11:29 +0200
    Re: State Machine Compiler für 8-bit AVRs? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-09-21 12:26 +0200
      Re: State Machine Compiler für 8-bit AVRs? Andreas Weber <info@tech-chat.de> - 2019-09-21 19:09 +0200
        Re: State Machine Compiler für 8-bit AVRs? Hergen Lehmann <hlehmann.expires.5-11@snafu.de> - 2019-09-21 20:37 +0200
          Re: State Machine Compiler für 8-bit AVRs? Andreas Weber <info@tech-chat.de> - 2019-09-22 12:48 +0200
            Re: State Machine Compiler für 8-bit AVRs? olaf <olaf@criseis.ruhr.de> - 2019-09-22 13:27 +0200
            Re: State Machine Compiler für 8-bit AVRs? Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-09-22 17:23 +0200
              Re: State Machine Compiler für 8-bit AVRs? Andreas Weber <info@tech-chat.de> - 2019-09-23 20:15 +0200
        Re: State Machine Compiler für 8-bit AVRs? Stefan Reuther <stefan.news@arcor.de> - 2019-09-22 10:48 +0200
        Re: State Machine Compiler für 8-bit AVRs? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-09-22 12:55 +0200
          Re: State Machine Compiler für 8-bit AVRs? Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-09-22 17:32 +0200
            Re: State Machine Compiler für 8-bit AVRs? Gerhard Hoffmann <dk4xp@arcor.de> - 2019-09-22 20:43 +0200
              Re: State Machine Compiler für 8-bit AVRs? Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-09-22 21:10 +0200
            Re: State Machine Compiler für 8-bit AVRs? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-09-23 00:34 +0200
              Re: State Machine Compiler für 8-bit AVRs? Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-09-23 09:12 +0200
                Re: State Machine Compiler für 8-bit AVRs? Gerhard Hoffmann <dk4xp@arcor.de> - 2019-09-23 14:15 +0200
                  Re: State Machine Compiler für 8-bit AVRs? Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-09-23 14:31 +0200
                    Re: State Machine Compiler für 8-bit AVRs? Stefan Reuther <stefan.news@arcor.de> - 2019-09-24 19:18 +0200
                      Re: State Machine Compiler für 8-bit AVRs? Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-09-24 20:47 +0200
                        Re: State Machine Compiler für 8-bit AVRs? Stefan Reuther <stefan.news@arcor.de> - 2019-09-25 17:51 +0200
                          Re: State Machine Compiler für 8-bit AVRs? Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-09-27 10:37 +0200
                            Re: State Machine Compiler für 8-bit AVRs? Stefan Reuther <stefan.news@arcor.de> - 2019-09-27 17:42 +0200
                              Re: State Machine Compiler für 8-bit AVRs? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-09-27 21:22 +0200
                                Re: State Machine Compiler für 8-bit AVRs? Stefan Reuther <stefan.news@arcor.de> - 2019-09-28 11:58 +0200
                                  Re: State Machine Compiler für 8-bit AVRs? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-09-28 13:48 +0200
                              Re: State Machine Compiler für 8-bit AVRs? Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-09-28 13:43 +0200
                  Re: State Machine Compiler für 8-bit AVRs? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-09-23 19:07 +0200
                    Re: State Machine Compiler für 8-bit AVRs? Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-09-23 20:08 +0200
    Re: State Machine Compiler für 8-bit AVRs? Gerhard Hoffmann <dk4xp@arcor.de> - 2019-09-22 13:40 +0200
      Re: State Machine Compiler für 8-bit AVRs? olaf <olaf@criseis.ruhr.de> - 2019-09-22 14:59 +0200

Page 2 of 2 — ← Prev page 1 [2]

#264625

On 25.09.19 17:51, Stefan Reuther wrote:

>> Nur weil einen Parser von Hand schreiben schwer ist, heißt das noch
>> lange nicht, dass einen Parser mit Generator schreiben leicht ist.
>>
>> Aber wenn ich ein Beispiel liefern würde, dann kann ich dir immerhin
>> versichern, dass das nicht so grütze-mäßig Segfaulten würde wie DoDis
>> Beispiel.
> 
> Da wäre ich mir nicht so sicher, denn Ressourcenmanagement zumindest mit
> yacc ist nicht einfach. Wer gackert muss auch legen.

Du vergisst die Messlatte: DoDi's Programm stürzt schon ab, wenn man es
lediglich STARTET.

Ich bin mir extrem sicher, dass ich ein Programm hinkriege, dass nicht
beim Start abstürzt. Eines, das nicht "F:\DoDi\..." als hardgecodete
Pfade enthält.

Und einen Parser kann man auch in einer Programmiersprache schreiben,
die Ressourcenmanagement übernimmt, ich bevorzuge Python wenn
Performance nicht kritisch ist.

> (Mein zweites größeres Parserprojekt war vor >20 Jahren bei "Jugend
> Forscht", ist also nicht so, dass ich nicht legen könnte.)

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

>>> *Das* ist Geschwätz. Selbstverständlich hat C++ eine Grammatik. Zu
>>> finden im Standard-Dokument unter "Annex A"
>>
>> Du kannst offenbar keine Standards lesen. Denn da steht ganz klar
>> zuerstmal: Annex A (informative) -- muss ich dir jetzt den Unterschied
>> zwischen informative und normative erklären?
> 
> Danke, sehr freundlich.

Na du musst dich schon entscheiden. Entweder du unterstellst mir
Geschwätz, kannst das ordentlich belegen und ich halte meine Schnauze.
Oder du unterstellst mir Geschwätz, lieferst unzureichende Belege und
bekommst eine entsprechend unfreundliche Antwort. Beides geht nicht.

> (Mein ca. fünftes größeres Parserprojekt war
> Teil eines C++-Compilers für das VFiasco-Projekt. C++-Standard kenn ich.)

Mag ja sein, trotzdem hast du einen INFORMATIVEN Teil als "Beleg"
angeführt. Einen Teil, der also als Beleg völlig untauglich ist, weil er
formal eben NICHT Teil der Spezifikation ist. Und selbst wenn er es wäre
ganz klar drin steht, dass es eben nicht den Sprachumfang abdeckt.

>> Und dann nochmal überdeutlich: "This summary of C ++ syntax is intended
>> to be an aid to comprehension. It is not an exact statement of the
>> language."
> 
> 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.

Und selbst die Fragmente sind horrend unvollständig. Ich nehme mir ein
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.

>>> sowie in Fragmenten in den
>>> einzelnen Kapiteln. 
>>
>> Genau, verteilt über ~1300 Seiten, aber eben nicht ausdefiniert (und
>> genau das habe ich geschrieben, keine ausdefinierte Grammatik).
> 
> Was wäre denn eine "ausdefinierte Grammatik"?

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.

> Die ernsthafte Schwäche, die diese Grammatik hat, ist, dass sie zwischen
> den Ebenen "lexikalische Analyse", "Präprozessor" und "syntaktische
> 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.

Ich würde sagen, die ernsthafteste Schwäche sind die extrem
komplizierten Disambiguation Regeln. Die wirklich korrekt zu
implementieren ist (auch aufgrund der mangelhaften Definition als
textuelle Repräsentation) extrem schwierig und das zeigt sich auch immer
wieder bei Beispielen, die von einem Compiler gefressen werden und von
einem anderen nicht.

C++ ist halt Stückelwerk. Außerdem sind ihnen offenbar irgendwann die
Tokens ausgegangen, sonst hätten wir nicht jahrelang elendige Probleme
gehabt mir trivialsten Mist wie

std::vector<std::vector<std::string>>

bzw eben der früher notwendigen Variante

std::vector<std::vector<std::string> >

Wenn mich meiner Errinerung nicht täuscht, sind die ntowendigen
Disambiguation Regeln dafür erst mit C++11 dazugekommen. Das ist einfach
nur gruselig.

Gruß,
Johannes

-- 
"Performance ist nicht das Problem, es läuft ja nachher beides auf der
selben Hardware." -- Hans-Peter Diettrich in d.s.e.

[toc] | [prev] | [next] | [standalone]

#264671

Am 27.09.2019 um 10:37 schrieb Johannes Bauer:
>>> Und dann nochmal überdeutlich: "This summary of C ++ syntax is intended
>>> to be an aid to comprehension. It is not an exact statement of the
>>> language."
>>
>> 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.
> 
> Und selbst die Fragmente sind horrend unvollständig. Ich nehme mir ein
> 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 nennt sich - ich wiederhole mich - semantische Bedingungen. Von
Trivialitäten wie Brainfuck abgesehen kommt kaum eine Sprache ohne aus.

>>>> sowie in Fragmenten in den
>>>> einzelnen Kapiteln. 
>>>
>>> Genau, verteilt über ~1300 Seiten, aber eben nicht ausdefiniert (und
>>> genau das habe ich geschrieben, keine ausdefinierte Grammatik).
>>
>> Was wäre denn eine "ausdefinierte Grammatik"?
> 
> 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.

Du kannst die Grammatik einem ausreichend fähigen Parsergenerator
vorlegen. Der wird dann halt *mehr* erkennen als nur gültige
C++-Programme, da die semantischen Bedingungen die gültigen Programme
*einschränken* ("eine Variable muss vor der Verwendung deklariert sein"
usw.).

>> Die ernsthafte Schwäche, die diese Grammatik hat, ist, dass sie zwischen
>> den Ebenen "lexikalische Analyse", "Präprozessor" und "syntaktische
>> 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.
> 
> Ich würde sagen, die ernsthafteste Schwäche sind die extrem
> komplizierten Disambiguation Regeln. Die wirklich korrekt zu
> implementieren ist (auch aufgrund der mangelhaften Definition als
> textuelle Repräsentation) extrem schwierig und das zeigt sich auch immer
> wieder bei Beispielen, die von einem Compiler gefressen werden und von
> einem anderen nicht.

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

> C++ ist halt Stückelwerk. Außerdem sind ihnen offenbar irgendwann die
> Tokens ausgegangen, sonst hätten wir nicht jahrelang elendige Probleme
> gehabt mir trivialsten Mist wie
> 
> std::vector<std::vector<std::string>>
> 
> bzw eben der früher notwendigen Variante
> 
> std::vector<std::vector<std::string> >
> 
> Wenn mich meiner Errinerung nicht täuscht, sind die ntowendigen
> Disambiguation Regeln dafür erst mit C++11 dazugekommen. Das ist einfach
> nur gruselig.

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.)

In C++ hat man halt eine Sonderbehandlung für diesen einen Fall eingebaut.


  Stefan

[toc] | [prev] | [next] | [standalone]

#264686

Am 27.09.2019 um 17:42 schrieb Stefan Reuther:

> 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.

Schon K&R hat >>, ==, ++ usw. als eigenständige Tokens definiert. Selbst 
für +++ wurde geregelt, welche Tokens das ergibt. Und wenn wir schon 
dabei sind, das "dangling else" wird auch weit einfacher in der 
semantischen Prüfung des Parsers aufgelöst als in der Grammatik.

Mich stört da mehr das "long long", das eine eigene Bedeutung erhalten 
hat, nicht aber "short short". Ist eigentlich heutzutage auch "long 
signed long" ein gültiger Typ, und wenn ja welcher?

> Solche Effekte gibt es in vielen Sprachen. Pascal:
>
>      a := sqrt(.5);
>
> (parsed nicht, weil '(.' als '[' interpretiert wird.)

Sofern man Digraphen als Option eingeschaltet hat. Heutige Compiler 
kennen möglicherweise garkeine Di-/Trigraphen mehr, oder ignorieren sie 
per Default. Delphi unterscheidet inzwischen sogar Kommentare in { } und 
(* *), die eigentlich gleich interpretiert werden müßten. So kann man 
ganze Codeblöcke mit Kommentaren ggf. nochmal mit der anderen 
Schreibweise auskommentieren.

DoDi

[toc] | [prev] | [next] | [standalone]

#264701

Am 27.09.2019 um 21:22 schrieb Hans-Peter Diettrich:
> Am 27.09.2019 um 17:42 schrieb Stefan Reuther:
>> 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.
> 
> Schon K&R hat >>, ==, ++ usw. als eigenständige Tokens definiert. Selbst
> für +++ wurde geregelt, welche Tokens das ergibt. Und wenn wir schon
> dabei sind, das "dangling else" wird auch weit einfacher in der
> semantischen Prüfung des Parsers aufgelöst als in der Grammatik.
> 
> Mich stört da mehr das "long long", das eine eigene Bedeutung erhalten
> hat, nicht aber "short short". Ist eigentlich heutzutage auch "long
> signed long" ein gültiger Typ, und wenn ja welcher?

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

Dafür gibt es wenigstens einen Compiler, der "long short" für einen
24-Bit-Typen kennt (MPLAB C18). Was sollte denn "short short" sein? Bei
den üblichen Größen mit "char" = 8 Bit, "short" = 16 Bit bliebe ja nur
ein 12-Bit-Typ übrig. Hardwareunterstützung dafür dürfte dann doch eher
selten in freier Natur anzutreffen sein. Einfach, weil sich der
Programmierer von der Straße nichts ohne 8-Bit-Bytes mehr vorstellen kann.

>> Solche Effekte gibt es in vielen Sprachen. Pascal:
>>
>>      a := sqrt(.5);
>>
>> (parsed nicht, weil '(.' als '[' interpretiert wird.)
> 
> Sofern man Digraphen als Option eingeschaltet hat. Heutige Compiler
> kennen möglicherweise garkeine Di-/Trigraphen mehr, oder ignorieren sie
> per Default.

Zumindest die Turbo-Pascal-Compiler hatten keine mir bekannte
Möglichkeit, das auszuschalten.

> Delphi unterscheidet inzwischen sogar Kommentare in { } und
> (* *), die eigentlich gleich interpretiert werden müßten. So kann man
> ganze Codeblöcke mit Kommentaren ggf. nochmal mit der anderen
> Schreibweise auskommentieren.

Das wiederum hatte Turbo Pascal auch.


  Stefan

[toc] | [prev] | [next] | [standalone]

#264712

Am 28.09.2019 um 11:58 schrieb Stefan Reuther:
> Am 27.09.2019 um 21:22 schrieb Hans-Peter Diettrich:
>> Am 27.09.2019 um 17:42 schrieb Stefan Reuther:
>>> 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.
>>
>> Schon K&R hat >>, ==, ++ usw. als eigenständige Tokens definiert. Selbst
>> für +++ wurde geregelt, welche Tokens das ergibt. Und wenn wir schon
>> dabei sind, das "dangling else" wird auch weit einfacher in der
>> semantischen Prüfung des Parsers aufgelöst als in der Grammatik.
>>
>> Mich stört da mehr das "long long", das eine eigene Bedeutung erhalten
>> hat, nicht aber "short short". Ist eigentlich heutzutage auch "long
>> signed long" ein gültiger Typ, und wenn ja welcher?
>
> "long signed long" ist das gleiche wie "long long".

Warum? Ich hätte auf "signed long" getippt.

> Dafür gibt es wenigstens einen Compiler, der "long short" für einen
> 24-Bit-Typen kennt (MPLAB C18). Was sollte denn "short short" sein? Bei
> den üblichen Größen mit "char" = 8 Bit, "short" = 16 Bit bliebe ja nur
> ein 12-Bit-Typ übrig. Hardwareunterstützung dafür dürfte dann doch eher
> selten in freier Natur anzutreffen sein. Einfach, weil sich der
> Programmierer von der Straße nichts ohne 8-Bit-Bytes mehr vorstellen kann.

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

>>> Solche Effekte gibt es in vielen Sprachen. Pascal:
>>>
>>>      a := sqrt(.5);
>>>
>>> (parsed nicht, weil '(.' als '[' interpretiert wird.)
>>
>> Sofern man Digraphen als Option eingeschaltet hat. Heutige Compiler
>> kennen möglicherweise garkeine Di-/Trigraphen mehr, oder ignorieren sie
>> per Default.
>
> Zumindest die Turbo-Pascal-Compiler hatten keine mir bekannte
> Möglichkeit, das auszuschalten.

Deshalb schrieb ich ja "heutige" Compiler :-]

DoDi

[toc] | [prev] | [next] | [standalone]

#264709

On 27.09.19 17:42, Stefan Reuther wrote:

>>> 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.
>>
>> Und selbst die Fragmente sind horrend unvollständig. Ich nehme mir ein
>> 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 nennt sich - ich wiederhole mich - semantische Bedingungen. Von
> Trivialitäten wie Brainfuck abgesehen kommt kaum eine Sprache ohne aus.

Klar, aber die Komplexität der in Prosa geschriebenen semantischen
Bedingungen übersteigt die der Grammatik eben bei Weitem. Der Effekt ist
bei C++ eben wirklich ausgeprägt.

>> 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.
> 
> Du kannst die Grammatik einem ausreichend fähigen Parsergenerator
> vorlegen. Der wird dann halt *mehr* erkennen als nur gültige
> C++-Programme, da die semantischen Bedingungen die gültigen Programme
> *einschränken* ("eine Variable muss vor der Verwendung deklariert sein"
> usw.).

Umso mehr Bedingungen es gibt, die diese Programme einschränken, umso
nutzloser ist die reine formale Grammatik. Weil dann kann ich
prinzipiell für jede Sprache eine allgemeingültige Grammatik angeben:

PROGRAM := chr(0..255)*

Supereinfach, und korrekt dazu. Parst jedes gültige C++-Programm. Und
halt noch mehr, als semantische Bedingung gebe ich an muss zusätzlich
den C++-Standard erfüllen. Feddich ist der Lack.

Ist aber halt super nutzlos, so eine Grammatik.

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

C ist im Vergleich zu C++ absoluter Kinderkram. Die Komplexität von C++
würde ich, bauchgefühlsmäßig, als mindestens Faktor 10 höher einschätzen.

>> Wenn mich meiner Errinerung nicht täuscht, sind die ntowendigen
>> Disambiguation Regeln dafür erst mit C++11 dazugekommen. Das ist einfach
>> nur gruselig.
> 
> 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.

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
mich meine Errinerung nicht täuscht, war eben

std::vector<std:vector<std::string>>

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
formale Definition eben unvollständig oder klobig ist. Da wackelt der
Schwanz mit dem Hund.

Gruß,
Johannes

-- 
"Performance ist nicht das Problem, es läuft ja nachher beides auf der
selben Hardware." -- Hans-Peter Diettrich in d.s.e.

[toc] | [prev] | [next] | [standalone]

#264340

Am 23.09.2019 um 14:15 schrieb Gerhard Hoffmann:
> Am 23.09.19 um 09:12 schrieb Johannes Bauer:

>> Immerhin, muss man dir zu Gute halten, hast du ausnahmsweise was
>> geliefert, statt immer nur heiße Luft zu produzieren. Auch wenn es jetzt
>> halt nicht dein Argument gestärkt hat, sondern exakt das Gegenteil
>> bewiesen.

Du hast nur bewiesen, daß Du einen Compiler nicht korrekt installieren 
kannst. Dein Problem, wenn dann benötigte Dateien nicht gefunden werden.


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

Laß gut sein, ich laß ihn weiter in meinem Filter schmoren. Mir fehlt 
nur noch ein Filter für Antworten auf seine Trollereien.


> Wirklich bewiesen hast du garnix. Du hast ein paar Exotencompiler
> aufgezählt die einen Parsergenerator benutzen,

Wobei ich mich frage, wie der C Preprozessor in einen generierten Parser 
eingebaut werden kann. Aber die Antwort kenne ich inzwischen schon, 
Johannes kann das latürnich ;-)

DoDi

[toc] | [prev] | [next] | [standalone]

#264343

On 23.09.19 19:07, Hans-Peter Diettrich wrote:

>>> Immerhin, muss man dir zu Gute halten, hast du ausnahmsweise was
>>> geliefert, statt immer nur heiße Luft zu produzieren. Auch wenn es jetzt
>>> halt nicht dein Argument gestärkt hat, sondern exakt das Gegenteil
>>> bewiesen.
> 
> Du hast nur bewiesen, daß Du einen Compiler nicht korrekt installieren
> kannst. Dein Problem, wenn dann benötigte Dateien nicht gefunden werden.

Aaaaaaaahahahahahaha!

Ja, klar. Wenn Dateien nicht gefunden werden, versucht er mal auf
Adresse 0x7 zuzugreifen und löst eine allgemeine Schutzverletzung aus.
Ist klar, die Fehlerbehandung der Profis. Perfekte Erklärung!

Gott, du bist so armselig mit deinen dumm-dreisten Ausreden und
ständigen Herumlügereien. Ekelhaft und widerlich.

> Laß gut sein, ich laß ihn weiter in meinem Filter schmoren.

Neeeeeeeeein oh neeeeeeein, die allerschlimmste Strafe von allen. In
deinem Filter zu "schmoren". Jetzt entgehen mir deine altklugen
Ratschläge also in Zukunft, ich bin untröstlich.

> Mir fehlt
> nur noch ein Filter für Antworten auf seine Trollereien.

Dass du nicht mal in der Lage bist, einen Newsreader zu bedienen,
überrascht sicherlich niemanden mehr.

Alles Liebe,
Dein Johannes

-- 
"Performance ist nicht das Problem, es läuft ja nachher beides auf der
selben Hardware." -- Hans-Peter Diettrich in d.s.e.

[toc] | [prev] | [next] | [standalone]

#264265

Am 21.09.19 um 11:29 schrieb Andreas Weber:
> Hallo an alle,
> 
> ich verwende seit knapp 4 Jahren immer wieder den Ragel [1] Generator
> für Parser auf Atmel/Microchip AVRs z.B. für UART Empfangsroutinen.
> 
> Was verwendet ihr so, sobald die Grammatik etwas komplizierter wird? Lex
> wäre ja auch eine Möglichkeit.
> 
> TIA, Gruß Andy
> 
> [1] https://www.colm.net/open-source/ragel/
> 

Den kannte ich noch nicht, danke für's Aufschlauen.

Mit dem guten alten yacc und seinen Nachfahren (bison) müsste
es auch gehen. Links/rechts-rekursiv mit 1 token look-ahead.
Hat bisher bei mir für alles gereicht.

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

Der yacc war übrigens ursprünglich nicht für den Compilerbau
vorgesehen, sondern zum automatisierten Übersetzen von Zustands-
Automaten in Weinberger-Arrays. Weinberger-Arrays sind so was
ähnliches wie PALs, nur älter und nur maskenprogrammierbar.

Das ist der gleiche Weinberger, der für das W in awk steht.
(Aho, Weinberger, Kernighan). Die ganze UNIX/C-Truppe bei AT&T
waren eigentlich Halbleiterleute und Digitaldesigner.
Unix und C waren nur "Abfallprodukte".

Gruß, Gerhard

[toc] | [prev] | [next] | [standalone]

#264268

Gerhard Hoffmann <dk4xp@arcor.de> wrote:

 >(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

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | de.sci.electronics

csiph-web