Wie geht es weiter?
Hallo @All
Ich habe am Samstag mal versucht, die Tiefen eines S7-Projektes zu ergründen. Leider bin ich da nicht soweit gekommen, wie ich mir das gewünscht hatte, da mich wohl ein Virus erwischt und mir somit den Schädel verdreht hat. :shock: :shock: :shock:
Aber trotzdem ist doch etwas dabei herausgekommen. So konnte ich zumindest orten:
- wo Quelltexte (SCL und AWL) in ASCII abgelegt werden;
- wie die v.g. Quelltexte katologisiert sind;
- wo AWL-Code (MC7-Code??) abgelegt werden;
- wo Symbollisten abgelegt werden.
Dies mal vorab.
seeba schrieb:
Jochen Kühner schrieb:
Ich denke die Programmierung einer Kopletten programier IDE muss ja nicht von Grund auf erfolgen. Es gibt ja schon einige OpenSource IDE's welche funktionen wie syntaxhilighting bieten. Ich denke man könnte ja einfach so ein projekt für unsere zwecke erweitern. Dadurch müsste ja trotzdem nicht unser ganzes projekt unter eine open source lizenz fallen da der compiler ja als extra programm dazu entworfen werden kann...
Ich denke das Hauptaugenmerk sollte ja sowiso an der Compilerentwicklung und der optimierung desen Encodes sein!
Ja, sollte es! Nur wie fangen wir jetzt an? Sollten wir eine Art Vokabelliste erstellen?
Womit fangen wir an? Ich bin der Meinung, dass wir die Arbeit unterteilen müssen. Deshalb hatte ich in der letzten Woche mal meine Ideen skizziert, wie man ein derartiges Projekt realisieren könnte. Das sollten wir diskutieren und das alles unter dem Gesichtspunkt, wer wo seine Stärken sieht usw.usf. Aus der Diskussion sollte sich herausstellen, wer sich mit wem zu einer Arbeitsgruppe zusammenschließen kann, denn es macht ja keinen Sinn, wenn jeder das gleiche machen will und andere wichtige Punkte der Arbeit damit unberücksichtigt bleiben. Ich halte es für richtig, eine bestimmte Reihenfolge einzuhalten. Wenn man die ersten 3 Teile nach meinem Vorschlag realisieren wollte, dann sind wir vorläufig nicht auf einen eigenen Editor angewiesen. Um die Teilergebnisse zu testen, reicht es, mit einem externen Editor den C-Code zu erfassen und als ASCII-Datei zu speichern, das befreit uns für den Augenblick von unnötigen Hürden.
Aus der Vorstellung meiner Ansicht der letzten Woche:
Teil 1: Preprozessor
Teil 2: Parser
Teil 3: Code-Generator nach AWL
Den Preprozessor müssten wir noch weiter spezifizieren:
- er formatiert die Textdatei mit dem C-Code. Unter der Formatierung verstehe ich:
-- dass der Quelltext von Kommentaren "befreit" wird;
-- dass unnötige Leerzeichen und Zeilenumbrüche (soweit erforderlich) entfernt werden;
-- dass Makros substituiert werden;
-- dass untersucht wird, ob C-spezifische Formalien eingehalten worden sind;
Der Preprozessor erstellt somit eine Zwischendatei, die einen "bereinigten" Quelltext enthält. Um Fehlerausschriften des Preprozessors zu ermöglichen, muss eine Liste mit Referenzen erstellt werden, mit denen der Hinweis auf den Originaltext möglich ist. Usw.usf.
Hier kann noch diskutiert werden, was der Preprozessor sonst noch alles können sollte!
Die Parser nimmt die von dem Preprozessor erstellte Zwischendatei:
- er sucht nach C-Sprachmitteln (reservierte Schlüsselwörter und Operatoren), die für diesen Compiler zugelassen sind und markiert deren Position in einer Liste;
- er erfaßt symbolisierte Variablen und trägt diese in eine Liste (Liste 1) ein sowie deren Typ;
- er generiert eine weitere Liste (Liste 2) mit Einträgen als Referenz auf die Liste 1;
- er löst C-Konstrukte unter Beachtung der Vorrangregeln auf;
- er löst Klammern auf und bestimmt die Rangfolge von Operationen;
Auch hier sind noch weiter Vorschläge erwünscht! Der Parser ist somit der schwierigste und aber auch der wichtigste Teil des Compilers.
Wenn der Parser seine Arbeit getan hat, müssen mit dem Codegenerator die C-Konstrukte in AWL-Code umgesetzt werden. Die Erstellung des Code-Generators erscheint mir aber im Vergleich zu dem Parser fast wie ein Kinderspiel. Die Funktionen des Code-Generators setzten aber auf die Regeln auf, die für den Bau des Parsers entwickelt werden, deshalb kann man mit dem Code-Generators wahrscheinlich erst beginnen, wenn die genauen Funktionen des Parsers bestimmt worden sind.
Jochen Kühner schrieb:
.... Es gibt ja schon einige OpenSource IDE's welche funktionen wie syntaxhilighting bieten. Ich denke man könnte ja einfach so ein projekt für unsere zwecke erweitern. Dadurch müsste ja trotzdem nicht unser ganzes projekt unter eine open source lizenz fallen da der compiler ja als extra programm dazu entworfen werden kann...
Zum Stichwort "OpenSource" fällt mir ein, dass zum Thema der rechtlichen Klärung noch ein Einvernehmen erzielt werden muss. Wenn Rainer einiges zu diesem Projekt beisteuern kann, das wir dann nicht mehr entwickeln müssen, dann kann unser Projekt sicher nicht unter dem Begriff von Opensource gehandelt werden. Solange wir nicht mehr entwickeln als die von mir thematisierten ersten 3 Punkte, sind wir relativ frei. Wird aber das Projekt um einen Editor erweitert, dann macht dieser auch nur wirklich einen Sinn, wenn wir ein Compilat problemlos ohne Umwege in ein S7-Projekt integrieren können. Dieses Vorgehen ist aber mit Knochenarbeit verbunden, da man sich den MC7-Code erarbeiten muss - wer's nicht glaubt, der versuche es einmal mit googeln, um an Quellen für MC7-Code heranzukommen - Rainer würde den Part beisteuern wollen, wenn wir hier ein Einvernehmen erzielen - siehe hierzu mein Thread zum Thema "rechtliche Klärung".
Die Arbeiten zum Preprozessor könnten wir nach meiner Ansicht relativ bald beginnen. Die Arbeiten zum Parser setzen einige Vorarbeiten voraus, denn sicher können wir nicht jede C-Konstruktion in AWL umsetzen. Auch wird es notwendig sein, zu klären, in welchem Umfang ein S7-C-Compiler überhaupt angewendet werden kann. Nach meiner Ansicht beschränkt sich dessen Anwendung auf den Bau von FB's bzw. FC's.
Ich bitte darum, dass sich jeder einmal Gedanken macht, welches Feld im liegt.
- Wer will beim Proprozessor mitmachen?
- Wer arbeitet bei den Voruntersuchungen zum Parser mit?
- Wer arbeitet beim Parser?
Das sind einmal die Themenpunkte, die wir relativ schnell klären sollten.
Gruß Barnee