Gedanken zum C Compiler

Zuviel Werbung?
-> Hier kostenlos registrieren
Seit ihr damit einverstanden, dass ich vorerst die Projektführung machen soll? Ja/Nein?
Ja.

Könnt ihr euch mit dem von mir vorgestellten Stufeplan einverstanden erklären? Ja/Nein?
Ja.

Findet ihr die Unterteilung der Projekt so OK? Ja/Nein?
Ja.

Sicher müsste man den Preprozessor noch feiner definieren. Denke da z.B. an Übernahme von Symbolen aus einen S7-Projekt.
 
Barnee schrieb:
Findet ihr die Unterteilung der Projekt so OK? Ja/Nein?
Als Grobstruktur Ja. Muss natürlich in weitere Feinschritte gegliedert werden. Deshalb auch meine Anmerkungen zu dem was als nächstes kommen sollte (ohne Hüte haben zu wollen, ich stehe unter dem Pantoffel, da ein Hut keinen Platz mehr :lol: ). Dies war ein Anfang der Aufteilung von Stufe 1.[/quote]

Speedy schrieb:
Sicher müsste man den Preprozessor noch feiner definieren. Denke da z.B. an Übernahme von Symbolen aus einen S7-Projekt.

Klar doch, was denn sonst? Um aber aus den Pantoffeln zu kommen :ROFLMAO: muss man natürlich erst einmal versuchen, ein Pack-Ende zu finden. Das mit den Symbolen war mir aber schon klar, das hatte ich auch schon in dem Zusammenhang mit dem Editor erwähnt.

Gruß Barnee
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Programmabaluf...

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!
 
Re: Programmabaluf...

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?
 
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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Guten Morgen zusammen,
ich für meinen Teil sehe im Codegenerator die größten Schwierigkeiten (jedenfalls bei dem Teil, bei dem ich glaube dass er zum Codegenerator gehört). Da tauchen bei mir ganz viele Fragen auf. Z.B. wie wird aus welchem C-Konstrukt welcher AWL-Code generiert. Wenn ich eine ganz normale Funktion ansehe die einen Pointer als Argument hat, wird dieses dann als IN, OUT oder als INOUT verwendet? Ist jede Funktion nachher ein eigener Baustein, der beliebig aufgerufen werden kann? Wie erhalten wir eine effiziente Umsetzung unter Ausnutzung des kompletten Befehlsatzes (auch wenn vielleicht für viele nacher nicht verständlich)? Die Liste lässt sich beliebig forstetzen. Wer hat hier schon Ideen?
Für Teil 1 und 2 werden wir sicher einiges im Internet und bei der Abteilung Informatik finden, das wir verwenden können und dürfen. Teil 3 ist aber absolutes Neuland (SCL ausgenommen, aber da haben wir sowieso keinen Zugriff darauf :wink: )
Das ganze in Arbeitsgruppen aufzuteilen finde ich gut. Dadurch erreichen wir eine gewisse Parallelisierung. Wo ich mitmache ist mir in Prinzip egal. Aber folgende Abschnitte kann ich bereits mitbringen (wenn wir uns rechtlich einig sind): Zugriff auf des original S7-Projekt (lesend und schreibend), Zugriff auf die Symbolik inkl. Auflösung der DBs mit UDTs ..., Übersetzung von AWL nach MC7 einschließlich Generierung eines kompletten Bausteines mit allen Siemen-Erfordernissen, Aufbau der AWL-Makros die wieder Unmengen von MC7-Code erzeugen (z.B. Bausteinaufrufe mit Parametern), Kommunikation zur S7 inkl. Statusfunktionen.
 
Guten Morgen Rainer

Wenn für dich der Teil 3 als der schwierigere Teil erscheint, dann sehe ich die absolute Notwendigkeit, diese Details im einzelnen zu diskutieren, denn für mich erscheint Teil 3 (Code-Generator) als der leichteste und der Teil 2 (Parser) als der schwierigste.
Das zeigt, das wir mit einander reden/diskutieren müssen, um unsere Ansichten und Meinungen auf einen Nenner zu bringen.
Nach meiner Ansicht kann man den Parser in mehrere Teile zerlegen. Ich werde das später an Hand von Beispielen versuchen darzulegen, wie der Parser arbeiten muss. Hier mal ein kleiner Vorgeschmack:

Code:
a = (((b && c) || (d && e) && f) || g) && h;

Das ist eine typische Sequenz, die man bei der Bitbumserei unter AWL immer wieder sehen kann. Sicher kann man die o.g. Zeile noch optimieren, aber ich hab die ohne lange nachzudenken hier mal soeben "hingesaut".

Die Aufgabe des Parsers ist z.B. die o.g. Zeile aufzulösen, ggf. mit einer Metasprache zu übersetzen, so dass quasi ein Vorprodukt erzeugt wird, das von dem Code-Generator nur noch in AWL übertragen werden muss.

Hier kann die Anwendung von C++ hilfreich sein, wenn man die Bestandteile der o.g. Zeile mit Objekten assoziiert. In C++ sind ja Objekten feste Regeln zugeordnet. Der Ausdruck in der ersten inneren Klammer wäre demnach ein UND-Objekt so wie auch der Ausdruck in der zweiten inneren Klammer. Die nächst höhere Klammer ist ein ODER-Objekt und umfasst die beiden v.g. UND-Objekte usw.usf.

Beim Auflösen der Klammerungen, muss man zunächst die Anzahl von Klammerebenen feststellen, die Ebene mit der höchsten Ziffer hat die höchste Priorität und beginnt auf der gleichen Ebene von links nach rechts usw. usf..

Gruß Barnee
 
So ein sauber geklammerter Ausdruck schockt mich noch nicht. Die Auflösung würde ich einfach mit Hilfe von Rekursion erledigen. Das können wir mal gerne im Detail diskutieren. Festgelgt werden muss nur die Operandenreihenfolge (und vor oder, oder nicht?). Notfalls zur Klärung Klammern einfügen, das könnte ja der PP machen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Rainer + @All

Rainer Hönle schrieb:
So ein sauber geklammerter Ausdruck schockt mich noch nicht.
Mich auch nicht :ROFLMAO: :ROFLMAO: :ROFLMAO:
Sollte ja als ein kurzes Beispiel dienen, um überhaupt einmal in die Diskussion einzusteigen.

Rainer Hönle schrieb:
Die Auflösung würde ich einfach mit Hilfe von Rekursion erledigen.
Fullack!

Rainer Hönle schrieb:
Das können wir mal gerne im Detail diskutieren. Festgelgt werden muss nur die Operandenreihenfolge (und vor oder, oder nicht?). Notfalls zur Klärung Klammern einfügen, das könnte ja der PP machen.
Es sollten schon die in C üblichen Regeln gelten. Ich bin der Meinung, dass man spezielles auf AWL ausgerichtetes C besser nicht entwickeln sollte. Das was S7 spezifisch ist, sollte dann doch eher der Parser abfangen. Ich stelle mal nachfolgend eine Tabelle ins Forum:
Code:
Vorrangtabelle der Operatoren

-----------------------------------------------------------
Priorität  Operator                         Zusammenfassung
-----------------------------------------------------------
 1.        ()   []   ->                     von links
 2.        !   ~   ++   --   -              von rechts
           *   &   sizeof
 3.        *   /   %                        von links
 4.        +   -                            von links
 5.        <<   >>                          von links
 6.        <   <=   >   >=                  von links
 7.        ==   !=                          von links
 8.        &                                von links
 9.        ^                                von links
10.        |                                von links
11.        &&                               von links
12.        ||                               von links
13.        ?   :                            von rechts
14.        =   +=   -=   *=   /=   %=       von rechts
           &=   ^=   |=   <<=   >>=
15.        ,                                von links
Leider ist die Tilde ~ in der 2. Zeile nicht deutlich zu erkennen. Weiss jemand wie man für Beiträge an dieser Stelle eine größere Schrift einstellt?

PP als Abkürzung für den Preprozessor find ich gut :lol: :lol: :lol:
Aus meiner Sicht würde ich gerne in der Arbeitsgruppe für den Parser arbeiten wollen, weil ich doch eine gute Vorstellung davon habe, wie so ein Ding funktionieren könnte. Ich werde mich jedoch auch gelegentlich in die Diskussionen um den PP (Preprozessor) einmischen.

Ich werde deshalb erst einmal 2 weitere Threads einrichten,
- vorläufig für die Themen zum PP;
- und für die Themen zum Parser.

Das war's erst einmal von dieser Stelle aus, das andere folgt in den entsprechenden Themengebieten.

Gruß Barnee
 
Dazu müsste man bei printf aber schon mindestens 2 Überladungen vorsehen.
Code:
printf(int cpaddr, string text)
Nee, man würde besser eine Version von open() implementieren, mittels derer man ein FILE* dem CP bzw. einer bestimmten Verbindung, die ein CP unterhält, zuordnet.
Danach kan fprintf() alles. Wenn man dann stdout einem solchen FILE* zuordnet, geht auch printf().
 
Warum über den Parser so lange nachdenken ...

Hallo zusammen,

es gibt doch bestimmt auch Open Source Projekte die z.B. die Mnemonics von PIC´s (Microchip Chips) usw. von C in HEX (MC7) Code umwandeln.
Also solchen Source mal zerpflügt und los kanns gehen.

Die restlichen Sachen sind im Forum ja bereits gelöst bzw. diskutiert


Grüße

matthias
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich habe >hier< gelesen das die Mitglieder dieses Projektes kein Opensource Projekt gestarted haben da her kann man auch kein Projekt das unter GPL oder änlichen Lizensen steht einfach ab ändern.
 
habe verstanden ...ä

Hi Zotos,

Danke für den Hinweis

Ich dachte hier sitzen die Anwender im Boot und keine kommerzielle
Vereinigung.....

Grüße

matthias
 
Ich würde so debuggen.

Ein kleines Tool schreiben, das mit Hilfe von libnodave die SPS-Variablen ausliest.
Die Ausgaben des Tools erlauben es dann das SPS Programm zu tracen.

z.B.
> ourtool # in terminal verfolgen
> ourtool | less # erlaubt auch pause und zurückblättern
> ourtool > ourlog.log # und dann
> grep pattern ourlog.log # oder
> tail -f ourlog.log

PS: Wie ist das mit dem C-Compiler für die SPS ?
Gibt's da Einen von Siemens ?
Soll der erst noch gebaut werden ?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ein kleines Tool schreiben, das mit Hilfe von libnodave die SPS-Variablen ausliest.
Die Ausgaben des Tools erlauben es dann das SPS Programm zu tracen.
Die S7 hat eingebaute Unterstützung für das Debuggen mittels Status-Ausgabe. Dazu teilt die PG-Software der CPU mit, an welcher Stelle in welchem Baustein sie den Status beobachten will. Die CPU speichert dann die Registerinhalte nach Ausführung jeder der sichtbaren? restlichen des Netzwerks? Anweisungen ab und sendet die Liste an das PG. Erst dieses Vorgehen erlaubt es, eine mehrfach verwendete Variable in einem bestimmten Kontext zu beobachten.
Libnodave liest nur Speicher(keine CPU-Register)inhalte ohne Bezug zum Programmkontext.

Um das S7-typische Debugging mit einem C-Quelltext machen zu können, müsste der Compiler halt eine Liste der Adressen korrespondierenden AWL (MC7)-Anweisungen und Quellcode-Zeilen erzeugen.
 
Ich habe >hier< gelesen das die Mitglieder dieses Projektes kein Opensource Projekt gestarted haben da her kann man auch kein Projekt das unter GPL oder änlichen Lizensen steht einfach ab ändern.
Das zwar nicht, aber man darf open source-Werkzeuge einstzen, also lexx und yacc. Ein C-Parser (oder Teile davon) gehört sowieso zu den "Lehrbuchbeispielen" für yacc. Und man darf wohl in den Code schauen und sich mal die Syntax-Beschreibungsdatei ansehen, die einen solchen Parser generiert. Der SDCC (C-Compiler für Mikrocontroller) verwendet einen yacc-generierten Parser.
 
Das zwar nicht, aber man darf open source-Werkzeuge einstzen, also lexx und yacc. Ein C-Parser (oder Teile davon) gehört sowieso zu den "Lehrbuchbeispielen" für yacc. Und man darf wohl in den Code schauen und sich mal die Syntax-Beschreibungsdatei ansehen, die einen solchen Parser generiert. Der SDCC (C-Compiler für Mikrocontroller) verwendet einen yacc-generierten Parser.


Da ich es dank Markus nun begriffen habe. Weis ich ja jetzt das es das Projekt nicht mehr gibt.

Bei einem Neustart kann man ja darüber diskutieren unter welcher Lizens das ganze laufen soll.

Wo bei mir der Compilerbau eh zu hoch ist.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

wie ist denn der Stand dieses Projektes? Gibt es Source Code? Ich wuerde die Idee eines C nach AWL Compilers gerne wieder aufgreifen. Wenn es Sourcen gibt, auf die man aufsetzen kann, dann um so besser :)
Ich ueberlege auch, ob ich einen AWL nach C Compiler schreibe, so dass ein ablauffaehiges C-Programm herauskommt, z.B. zum Testen der Logik bzw. als eine Art Soft-SPS.

VG,
sk
 
Zurück
Oben