# Gedanken zum C Compiler



## seeba (26 Januar 2006)

Hallo liebe Mitwirkenden,
ich habe mir mal ein paar Gedanken zu den Rahmenfunktionen gemacht:

Natürlich sollte er erstmal C zu AWL- oder besser MC7-Code "compilieren" können.
Ein Problem dürfte das Debugging werden, welches aber schon möglich sein sollte. Wenn sich das ganze etwas in den SIMATIC Manager integrieren könnte, wäre ganz schön, allerdings kenne ich die APIs nicht. Haltepunkte und Einzelschritte wären schon 'ne tolle Sache, aber ich frage mich gerade, wie man das am bestens umsetzt.
Soll das ganze ein Windows Programm werden, oder noch mehr Plattformen unterstützen? Ich denke Windows wäre ausreichen, da es sowieso keinen SIMATIC Manager unter Linux oder so gibt.

Gruß Sebastian


----------



## Rainer Hönle (26 Januar 2006)

seeba schrieb:
			
		

> Natürlich sollte er erstmal C zu AWL- oder besser MC7-Code "compilieren" können.


Hier ist die Frage der Umsetzung. Wer von uns hat Erfahrung mit Compilerbau, Syntaxbäumen und dem Ganzen darumherum. Ansonsten bleibt uns nur in erster Fassung ein 1:1-Übersetzer. Beim ProSys hatten wir das Ganze auch. Allerdings ist der damalige Entwickler (Informatiker) mittlerweile direkt bei 3S.



			
				seeba schrieb:
			
		

> Ein Problem dürfte das Debugging werden, welches aber schon möglich sein sollte. Wenn sich das ganze etwas in den SIMATIC Manager integrieren könnte, wäre ganz schön, allerdings kenne ich die APIs nicht. Haltepunkte und Einzelschritte wären schon 'ne tolle Sache, aber ich frage mich gerade, wie man das am bestens umsetzt.


Der Status zu Zeiten unseres ProSys erfolgte auf Basis von Variablenstatus. Ein entsprechende Programmstatus mit Haltepunkte etc. war nicht möglich. Meine Kenntnisse des Simatic-Managers reichen momentan auch nicht aus, um ihn um diverse Programme zu erweitern. Habe allerdings auch noch nicht gebohrt. Eine Integration in unser S7-PG (ok, es bekomt  noch Hardwarekonfig etc.) ist da einfacher möglich. Auch können wir den erzeugten Code direkt in ein originales Step7-Projekt einfügen. 



			
				seeba schrieb:
			
		

> Soll das ganze ein Windows Programm werden, oder noch mehr Plattformen unterstützen? Ich denke Windows wäre ausreichen, da es sowieso keinen SIMATIC Manager unter Linux oder so gibt.


Das ist jetzt eine Glaubensfrage. Aber unter Linux wird es eher schwierig. Ich würde vorschlagen, dass wir mit Windows anfangen und Linux soweit möglich nicht sofort ausschließen. Aber zuerst müssen wir die Grundlagen schaffen.
Momentan untersuchen wir bei uns qt in der Version 4.1, da wir einige portable Applikationen benötigen. Mal sehen wie das voran geht.


----------



## Speedy (26 Januar 2006)

Den Compiler könnte man als reine Konsolen Anwendung programmieren. Ließe sich auch besser auf andere Systeme portieren.
Bei dem Debugger sehe ich so meine Probleme mit Breakpoint. Man kann ja nicht sie SPS so einfach stehen lassen wenn sich irgendwo etwas bewegt.
Ein Debugger wie in SCL auf Variablenstatus währe aber schon möglich.
Um Portable zu sein währe qt eine Möglichkeit. Gibt es auch als Freeware.

Gruß Zbynek


----------



## seeba (26 Januar 2006)

Speedy schrieb:
			
		

> Den Compiler könnte man als reine Konsolen Anwendung programmieren. Ließe sich auch besser auf andere Systeme portieren.
> Bei dem Debugger sehe ich so meine Probleme mit Breakpoint. Man kann ja nicht sie SPS so einfach stehen lassen wenn sich irgendwo etwas bewegt.
> Ein Debugger wie in SCL auf Variablenstatus währe aber schon möglich.
> Um Portable zu sein währe qt eine Möglichkeit. Gibt es auch als Freeware.
> ...



Also bei SCL kann ich Breakpoints setzen?


----------



## Speedy (26 Januar 2006)

Beim SCL kann man keine Breakpoints setzen. 
Ein Debugger wie in Visual Studio kann man für ein SPS Projekt nicht gebrauchen. Die Steuerung muss zum jedem Zeitpunkt weiter laufen.


----------



## Rainer Hönle (26 Januar 2006)

Speedy schrieb:
			
		

> Um Portable zu sein währe qt eine Möglichkeit. Gibt es auch als Freeware.


Gibt es als GPL. Nur wenn alles was damit erstellt wurde auch der GPL unterliegt, also Open Source ist, dann darf diese Version verwendet werden. Bei Open Source bin ich allerdings etwas zugeknöpfter, da ich in das Projekt etwas von dem bei uns über Jahre erarbeiteten KnowKnow einbringen würde. Und das sollte nicht jeder für lau bekommen, denn mit etwas muss ich meine Brötchen ja auch verdienen  :wink: 
Die Frage ist sowieso noch, was wir mit dem Teilchen wollen. Zeigen dass wir (vielleicht) gut sind oder Geld verdienen?


----------



## seeba (26 Januar 2006)

Rainer Hönle schrieb:
			
		

> Zeigen dass wir (vielleicht) gut sind oder Geld verdienen?



Beides...? 

Wir könnten den Code allerdings auch mit libnodave auf die SPS bringen.

Ich hab schon Breakpoints gesetzt. Da kann mir keiner was erzählen!


----------



## Rainer Hönle (26 Januar 2006)

seeba schrieb:
			
		

> Ich hab schon Breakpoints gesetzt. Da kann mir keiner was erzählen!


Natürlich kann die S7 je nach Steuerung Breakpoints und Einzelschrittbearbeitung in beschränkter Anzahl. Dieser Testbetrieb ist nur für die normale Umgebung/Produktion suboptimal da wirklich der Prozess stehen bleibt. Um logische Programmierprobleme zu entdecken steht ja PLCSim oder ACCONtrol :wink: zur Verfügung.


----------



## seeba (26 Januar 2006)

Rainer Hönle schrieb:
			
		

> seeba schrieb:
> 
> 
> 
> ...



Ja Haltepunkte setzt man ja auch nur für Debugging... Die sollten im normalen Betrieb nicht mehr im Programm sein.


----------



## Rainer Hönle (26 Januar 2006)

Und ist Status Bausteine auch Debugging?


----------



## Speedy (26 Januar 2006)

Den Debugger würde ich erstmal nach hinten schieben. 
Wir müssen erstmal etwas zum debuggen haben. 

Ich habe mir z. B. beim WinCC mit dem Standart Debugger von Visual Studio geholfen.

Gruß Zbynek


----------



## seeba (26 Januar 2006)

Speedy schrieb:
			
		

> Den Debugger würde ich erstmal nach hinten schieben.
> Wir müssen erstmal etwas zum debuggen haben.
> 
> Ich habe mir z. B. beim WinCC mit dem Standart Debugger von Visual Studio geholfen.
> ...



Klar brauch man den nicht sofort, aber man sollte ihn vorsehen!


----------



## Rainer Hönle (26 Januar 2006)

Speedy schrieb:
			
		

> Den Debugger würde ich erstmal nach hinten schieben.
> Wir müssen erstmal etwas zum debuggen haben.


Vollkommen richtig. Nur grundsätzlich beim Thema debuggen: was einen wirklich interessiert sind doch die Zustände der Variablen an bestimmten Programmstellen. Und das bekommen wir mit einem Status auf den Quellcode gemappt auch hin. Wichtig ist dabei allerdings, dass der Zustand der Variable beim Durchlaufen der Programmzeile angezeigt wird. Weiter unten könnte sie ja verändert werden. Da hilft nur Status Bausteine (@seeba: noch nicht Bestandteil von libnodave :wink: ).

@barnee: 
Wie wollen wir die ganze Sache angehen? Soll jeder seine Vorstellungen sammeln und zu Papier (äh Mail) bringen? 

@alle:
Wer hat welche Vorkenntnisse die für das Schreiben eines Compilers nützlich sind? Stichwort Lex und Yacc und all so ein Informatikergedöns.
In welcher Programmiersprache wollen wir den C-Compiler schreiben (ich weiss, komische Frage)? Brauchen oder wollen wir einen Editor dazu? Wenn ja, was soll der alles unterstützen? Welche C-Funktionen sind für den Anfang wichtig? ...

Mein Vorschlag: Jeder schreibt seine Fragen und Ansichten zusammen. Dann haben wir mal eine erste Diskussions-Grundlage.


----------



## Barnee (26 Januar 2006)

*Das fetzt ja schon richtig...*

Hallo und einen Guten Abend allseits.
Ich bin gerade erst aus dem Büro gekommen und wie ich sehe, ist die Diskussion schon richtig in Fahrt gekommen   

Supa, doa san mir joa richtig z'sammen   

Ich werd heute noch etwas Nachtschicht einlegen und mir alle Beiträge ansehen. Ein Diskussionspapier hab ich in Stichworten schon fertig. Ich werde versuchen, auf die verschiedenen Punkte schon mal einzugehen. Laßt mir ein wenig Zeit. Mein Vorschlag ist, erst einmal einen formalen Fahrplan zu erstellen/zu diskutieren, der Fahrplan soll vermeiden, dass wir unsere Resourcen vergeuden und damit den Spaß an der Sache verlieren.

Rainer hat schon einen wichtigen Punkt angesprochen. Es geht dabei um die rechtliche Situation, über die wir uns alle im Klaren sein sollten. Da die Programmierung von SPSen zu 99,8% immer einen kommerziellen Hintergrund hat, sollten wir unsere Arbeit nicht für lau abgeben. Wenn wir es schaffen sollten, den S7-C-Compiler zu erstellen, ist das immerhin ein Wettbewerbsvorteil, den wir für uns reklamieren sollten. Über das wie usw. usf. sollten wir zusammen sprechen.

Alles weitere stelle ich später ins Forum.

Gruß Barnee


----------



## Barnee (27 Januar 2006)

*Nachtschicht*

Hallo @all

So, jetzt hab ich mir doch glatt 'nen redaktionellen Job angeschafft     
Na ja, ich hab's ja auch nicht anders gewollt 8)  8)  8) 

Vorweg mal eine Feststellung: Wir wollen GUT sein und wir wollen ggf. auch etwas Geld verdienen! Gut wollen wir deswegen schon sein, weil wir es uns nicht leisten können, etwas schlechteres abzuliefern, als es Siemens manchmal tut. Deswegen alleine müssen wir schon besser sein und dann sind wir auch gut.

Ich arbeite derzeit an einem Projekt einer Sinteranlage (Erzsinterung zur Hochofenbeschickung) für Russland, WinCC, Step7 (neueste Version) mit aufgesetztem CFC (vergleichbar mit PCS7, aber eben eine etwas preiswertere Ausführung). Zeitweilig schlage ich mich mit dem CFC herum und mit dem, was der Compiler dabei so hinterlässt! Dort gibt es eine Möglichkeit einen CFC-Plan als FB zu übersetzen. Aber oh Graus, bei der Nachbearbeitung in SCL kann man den Code locker auf ca. 30% kürzen, ohne dass dabei der Informationsgehalt auch nur um ein einziges Bit geringer wird. Bei einer Nachbearbeitung in AWL sind dann noch einmal gute 20% an Optimierung möglich. Ich denke, wir haben ein gutes Potential, einen guten Compiler hinzubekommen, wenn man nicht die gleichen Fehler wie Siemens macht.

*Womit fangen wir an?*



			
				seeba schrieb:
			
		

> .... Natürlich sollte er erstmal C zu AWL- oder besser MC7-Code "compilieren" können.


Klar doch, das ist doch unser Thema. Doch wie weiter unten auch schon bemerkt wird, sollten wir mit dem einfachsten beginnen. Wir sollten uns den Weg zum Erfolg nicht zu schwierig gestalten. In meinem Diskussionspapier werde ich versuchen einen Weg aufzuzeigen, den wir gehen sollten.



			
				Rainer Hönle schrieb:
			
		

> Speedy schrieb:
> 
> 
> 
> ...


Ja richtig bemerkt, bis jetzt ist ja nur der Wunsch der Vater aller Gedanken. Und aus unseren Wünschen sollten Gelüste werden. Das wird dann der Fall sein, wenn wir erste kleine Erfolge vorweisen können, das wird dann der Fall sein, wenn wir die ersten kleinen Schritte machen.



			
				Rainer Hönle schrieb:
			
		

> @barnee:
> Wie wollen wir die ganze Sache angehen? Soll jeder seine Vorstellungen sammeln und zu Papier (äh Mail) bringen?


Wir sollten erst einmal das von mir vorgestellte Diskussionspapier zerfetzen. Jeder ist aufgerufen, seine Meinung dazu zu äußern und seinen Beitrag dazu zu machen. Ich hab mir zwar den redaktionellen Teil an den Hals geschafft    werde aber aktiv mitarbeiten. Wir sollten Beschlüsse gemeinschaftlich fassen, d.h. ich werde mich dem demokratischen Prinzip unterordnen und werde aber zu moderieren versuchen, damit für alle ein Erfolg gesichert ist.

*Welche Plattformen?*



			
				seeba schrieb:
			
		

> ...Soll das ganze ein Windows Programm werden, oder noch mehr Plattformen unterstützen? Ich denke Windows wäre ausreichen, da es sowieso keinen SIMATIC Manager unter Linux oder so gibt.....





			
				Rainer Hönle schrieb:
			
		

> ...Das ist jetzt eine Glaubensfrage. Aber unter Linux wird es eher schwierig. Ich würde vorschlagen, dass wir mit Windows anfangen und Linux soweit möglich nicht sofort ausschließen. Aber zuerst müssen wir die Grundlagen schaffen.
> Momentan untersuchen wir bei uns qt in der Version 4.1, da wir einige portable Applikationen benötigen. Mal sehen wie das voran geht.....


Nach meiner Ansicht stellt sich für den Augenblick nicht die Frage nach den Plattformen, zumindest nicht direkt. In meinem Diskussionspapier habe ich einmal grob eine Unterteilung in verschiedene Entwicklungsstufen vorgenommen sowie eine weitere Unterteilung in verschiedene Teilprojekte. Der Kern des Compilers sollte portierbar sein. Es ist mir schon klar, dass der S7-C-Compiler schlussendlich in seiner Gesamtheit nur auf einer Windoof-Kiste laufen wird. Aber...

Aber nach meiner Ansicht hängt es von den verschiedenen Arbeitsmethoden des Einzelnen ab, auf welcher Plattform eine Step7-Bausteinentwicklung stattfindet. Meine Arbeitsweise  findet nicht auf der Basis von Try&Error statt, sondern ich code meine Projekte meist zu 98% fertig, bevor ich ans testen denke. Seit einiger Zeit hat ja nun Siemens auch mal ans menschliche gedacht und ASCII-Schnittstellen für den Quellenaustausch geschaffen. Man möge mir die Bezeichnung "Windoof" verzeihen aber in meinem privaten Bereich arbeite ich auf Mac unter UNIX und da ist die Editieroberfläche eines Texteditors 10 mal besser als das was BG mit Microschrott bzw. Siemens zu bieten hat. Aber das soll uns hier nicht in zwei Lager spalten.

Daher meine Meinung: Soweit wie möglich sollte eine Unabhängigkeit von Plattformen doch schon erreicht werden. Daher sollte MFC nur dort eingesetzt werden, wo es wegen  HMI auf Windowkisten unumgänglich ist. Aber das sollten wir später noch im Detail diskutieren.

*Compilerbau*


			
				Rainer Hönle schrieb:
			
		

> ....Hier ist die Frage der Umsetzung. Wer von uns hat Erfahrung mit Compilerbau, Syntaxbäumen und dem Ganzen darumherum. Ansonsten bleibt uns nur in erster Fassung ein 1:1-Übersetzer....





			
				Speedy schrieb:
			
		

> ....Den Compiler könnte man als reine Konsolen Anwendung programmieren. Ließe sich auch besser auf andere Systeme portieren.....


Auch hier verweise ich auf mein Diskussionspapier weiter unten. Compilerbau ist nicht so schwierig, wie es den Anschein hat. Man kann den eigentlichen Compiler in verschiedene Teile (Prozessoren) zerlegen.

*Nach meiner Ansicht ist das der wichtigste Diskussionspunkt überhaupt, um den wir uns zu allererst kümmern sollten.*

Der Preprozessor und der Parser bedingen nach meiner Ansicht eine Menge vorarbeiten, die uns sicher keiner abnehmen wird. Denn der Gedanke, C-Programmierung von Step7-Bausteinen vornehmen zu wollen, orientiert sich m.E. nach dem, was mit dem MC7-Befehlsvorat realisiert werden kann. Anders als bei einem "richtigen" C-Compiler haben wir ja keinen direkten Zugriff auf den uP, sondern MC7 ist ja selbst ein Interpreter. Wir können also von den Methoden in C nur das übernehmen, was somit auch in MC7 umgesetzt werden kann. Somit sind üblich Libraries wie _stdio_, _math_ usw.usf. sicher nicht so ohne weiteres anwendbar. Aber lasst uns später darüber diskutieren.

*Debugging*


			
				seeba schrieb:
			
		

> ....Ein Problem dürfte das Debugging werden, welches aber schon möglich sein sollte. Wenn sich das ganze etwas in den SIMATIC Manager integrieren könnte, wäre ganz schön, allerdings kenne ich die APIs nicht. Haltepunkte und Einzelschritte wären schon 'ne tolle Sache, aber ich frage mich gerade, wie man das am bestens umsetzt....





			
				Rainer Hönle schrieb:
			
		

> Der Status zu Zeiten unseres ProSys erfolgte auf Basis von Variablenstatus. Ein entsprechende Programmstatus mit Haltepunkte etc. war nicht möglich. Meine Kenntnisse des Simatic-Managers reichen momentan auch nicht aus, um ihn um diverse Programme zu erweitern. Habe allerdings auch noch nicht gebohrt. Eine Integration in unser S7-PG (ok, es bekomt  noch Hardwarekonfig etc.) ist da einfacher möglich. Auch können wir den erzeugten Code direkt in ein originales Step7-Projekt einfügen.





			
				Speedy schrieb:
			
		

> ...Den Debugger würde ich erstmal nach hinten schieben.
> Wir müssen erstmal etwas zum debuggen haben....


Ich schließe mich da Speedy an. Zwar sollten wird den Gedanken nicht zu weit nach hinten schieben, sonst geht später irgendwann das Gefrikel los, um den Debugger in das Projekt einzubauen. An entsprechende Schnittstellen sollten wir schon denken. Wir sollten uns also schon Gedanken machen, welche Anforderungen ein Debugger erfüllen sollte.

*Freeware*


			
				Rainer Hönle schrieb:
			
		

> Speedy schrieb:
> 
> 
> 
> ...


Hier gebe ich Rainer vollkommen recht. Und darüber sollten wir uns im klaren sein. Auch jetzt schon! Wir werden ein paar Nahziele haben. Und auch diese Erfolge sollten wir nicht für lau aus der Hand geben. Selbst, wenn in dem SIMATIC-Forum unter meinem Thread teilweise mit gegensätzlicher Meinung argumentiert wurde, wird sicher ein Potential für einen S7-C-Compiler vorhanden sein. Einschränkend wird man sagen können, dass den S7-C-Compiler nicht jeder SPS-Programmierer anwenden wird, muß ja auch nicht jeder, einfache Bitbumserei kann man auch auf herkömmliche Art und Weise erzeugen. Aber in Bereichen, die ich z.B. bestens kenne, gibt es eine Vielzahl von Anwendungsmöglichkeiten. Mit den Nahzielen wird auch schon das Fernziel definiert, das heißt wir wollen versuchen, den S7-C-Compiler in den S7-Manager einzubinden. Ob und das gelingen könnte, werden wir untersuchen müssen.

*Diskussionspapier*
Ich stelle mir mehrere Entwicklungsstufen vor:

Stufe 1: nimmt Textdateien mit C-Code an und übersetzt in AWL (ASCII)
Stufe 2: Editor mit Syntax-Highlightning
Stufe 3: Erweiterung des Code-Generator für die Umsetzung nach MC7
Stufe 4: Einbindung in den Simatic-Manager
Stufe 5: Debugger

Die *Stufe 1* wäre somit unser erstes Nahziel. Mit dem Erreichen dieser Stufe hätten wir schon etwas, was man in der tägliche Arbeit anwenden könnte. Und wir könnten schon mal im SIMATIC-Forum etwas strunzen gehen      
Doch hier liegt schon der Teufel im Detail. Wir müssen uns schon hier Gedanken machen, welche Sprachmittel von C übernommen werden können. Das ist ein Thema für AWL-Spezialisten, ich schließe mich da ein, die Machbarkeit der Umsetzung zu prüfen, d.h. was ist in C adäquat zu AWL, das gilt es zu prüfen. Ich kenne verschiedene Beispiele aus der Umsetzung von SCL nach MC7, die sind m.E. grauenvoll. Aber das werden wir noch diskutieren.

Die *Stufe 2* sorgt schon für Komfort. Der Editor soll die C-Sprachmittel unterstützen. Ich habe hier auf dem Mac einen Editor, der schon etwas besonders ist. Vergleichsweise gibt es für Windows den Ultraedit, der auch nicht schlecht ist. Wir sollten uns z.B. auch überlegen, wie wir die Step7-Symbollisten vom Editor aus anwenden können. Selbstverständlich sollte der Editor auch Suchfunktionen beinhalten usw.usf. In der Diskussion um dieses Thema sind keine Schranken gesetzt, jeder konstruktive Beitrag ist willkommen.

In der *Stufe 3* sollte es wahlweise möglich sein, je nach Anforderung MC7-Code zu erzeugen, oder auch AWL, oder auch beides. Spätestens zu diesem Zeitpunkt sollten wird geklärt haben, wie wir eine Integration in den S7-Manager herstellen können (Stufe 4). Denn in einem Projekt, das z.B. mit CFC gemacht wird, wäre es sinnvoll, mit dieser Integration aufwarten zu können. Man kann zwar auch AWL-Bausteine in ein CFC-Projekt über die ASCII-Schnitstelle integrieren. Aber der direkte Weg wäre eleganter und überzeugender.

Die *Stufe 4* sollte die Einbindung in den S7-Manager darstellen. Ich weiß nicht, ob es ein Klacks ist oder ob es völlig unmöglich ist. Hier sind Leute gefragt, die vielleicht wissen, an welcher Stelle man bei Siemens bohren müsste. Zu S5-Zeiten hätte ich eine Lösung aus dem Ärmel geschüttelt aber das ist ja nicht mehr       

In der *Stufe 5* kommen wir endlich zu dem Debugger. Ich hab zur Zeit keinen Plan, wie man da vorgehen sollte. Es klang ja schon an, das man eine SPS eigentlich nicht anhalten kann. Ggf. sollte man überlegen, wie man die verfügbaren S7-Simulationen anwenden könnte. Ein anderer Gedanke wäre, eine eigene Simulation zu betreiben. MC7 ist ja im Prinzip kein direkt ausführbarer Code, d.h. wir könnten selbst einen Simulator erstellen, der unseren mit dem S7-C-Compiler erzeugten MC7-Code interpretiert.

Wenn ich bisher die Projektstufen vorgestellt habe, so darf nicht vergessen werden, dass das Projekt selbstverständlich aus verschiedenen Teilprojekten besteht. Ich stelle die Teilprojekte hier nur kurz vor, ohne dabei allzusehr in die Tiefe zu gehen:

Teil 1: Preprozessor
Teil 2: Parser
Teil 3: Code-Generator nach AWL
Teil 4: Editor
Teil 5: Code-Generator nach MC7
Teil 6: Debugger, ggf mit Simulator

Die Teilprojekte 1...3 fallen in die *Stufe 1*.

Unter einem *Preprozessor* verstehe ich einen Prozess, mit dem die C-Quelle erst einmal formgerecht auf Vordermann gebracht wird und erste Syntaxfehler erkannt werden. Makros müssen ebenfalls dort umgesetzt werden. Es müssen Listen erstellt werden mit Verweisen auf den Original-Quelltext, um *gezielte* Compilermeldungen absetzen zu können. Der unspezifische Hinweis, dass ein Fehler vorhanden ist, reicht m.E. nicht aus, die Fehlerausschriften des GNU-Compilers sollten mindestens unser Vorbild sein.

Der *Parser* fahndet nach Konstrukten, die mit C-Sprachmittel erstellt wurden. Er erstellt erste Listen mit Verweisen auf das Produkt des Preprozessors und löst C-Konstrukte auf. Der Parser ist die Vorstufe zum Code-Generator.

Der *Code-Generator nach AWL* besagt mit seinem Namen schon alles was er machen soll. Er erzeugt eine Textdatei, die mit "Bordmitteln" schon in die Step7-Umgebung eingebunden werden kann.

Alle bisher vorgestellten Teilprojekte sollten portierbar sein. D.h. hier verbietet sich m.E. der Einsatz von MFC, da dies propietäres Zeugs von BG ist. Es dürfte sicher keine Schwierigkeit sein, in C++ eigene Klassen zu entwerfen, die Plattform übergreifend portiert werden können. Das Wenige was an HMI notwendig ist, sollte über eine Schnittstelle auf diesen Kern zugreifen, so dass man für andere Plattformen, das notwendige HMI anpassen kann.

Der *Editor* besteht nach m.E. auch aus mehreren Teilen. Hier müßte noch fleißig diskutiert werden. Zumindest sollte der Kern des Editors auch nicht mit MFC erzeugt werden (gilt Gleiches wie bei den ersten drei Teilprojekten). Das HMI hängt natürlich wieder von der Plattform ab, aber auch hier sollte das über eine neutrale Schnittstelle geschehen.

Der *Code-Generator nach MC7*, ja das dürfte in dieseer Phase des Projektes eine einfache Sache sein. Wenn es da nicht eine z.Zt. unbekannte Größe gäbe: die Einbindung in den S7-Manager! Klar, das dieser teil des Code-Generator auf den dann bereits vorhandenen AWL-Code-Generator aufsetzt und somit MFC sicher nicht notwendig ist.

Der *Debugger* ist ein weites Feld für Diskussionen. Gibt es eine Möglichkeit direkt auf der S7-CPU zu arbeiten? Wenn nicht, könnte ich mir auch einen Simulator vorstellen, der außerhalb der CPU auf dem PC läuft. Macht man einen solchen Simulator von der CPU unabhängig, so sollte die Simulation auch unabhängig von der Plattform sein.


Der *rechtlichen Seite* des Projektes widme ich hier vorab ein paar Gedanken. Es dürfte wohl klar sein, das in den wenigsten Fällen jemand eine SPS zum ausschließlichen Spielvergnügen programmiert, sondern das es aus kommerziellem Antrieb erfolgt. Wenn in dem Laufe des Projektes kommerzielle Produkte einfließen, dann hat derjenige, der es beisteuert, ein Recht darauf, das dies nicht zum Vorteil von Dritten gerät. Wir werden daher ernsthaft über dieses Thema reden müssen. Ich für meinen Teil sehe dieses Projekt unter einem sportlichen Gesichtspunkt, was aber trotzdem heißt, dass ich mein Wissen ebenfalls nur im Kreise dieses Teams unentgeltlich angewendet wissen will, die Weitergabe an Dritte behandle ich ebenso wie ein Tabu. Unter Dritte verstehe ich jedweden, der sich außerhalb dieses Teams befindet.

Wir sollten die Vorschläge diskutieren und uns entsprechend dem Ergebnis in Arbeitsgruppen aufteilen. Für jede Arbeitsgruppe/Thema machen wir dann einen Thread auf, so dass die Themen nicht so wild durch einander gehen.

Noch was zu C++. Ich selbst bin im C mehr zu hause als im C++, hab aber das dicke Buch von Bjarne Stroustrup (alter Schwede) schon unter meinem Kopfkissen liegen      

So das war's für heute - Nachtschicht beendet 8)  8)  8) 


Gruß Barnee


----------



## Rainer Hönle (27 Januar 2006)

Guten Morgen zusammen,

für den Teil Code-Generator nach MC7 kann ich einiges beisteuern, d.h. der Punkt kann als erledigt geklennzeichnet werden. Ebenfalls das Schreiben der erzeugten Bausteine in ein originales Siemens-Projekt.
Der Zugriff auf die Symbolik ist ebenfalls gelöst, wenn es unter Windoof geschieht. Grund: Innerhalb der Projekte sind u.a. auch die Namen der wieteren Dateien und Datenbanken enthalten. Und so wie ich meine Freunde bei Siemens kenne, schreiben die Dateinamen in der Datenbank nicht unbedingt so wie beim Datei anlegen (Groß-Kleinschreibung). Damit haben wir natürlich unter Linux dann Probleme. ACHTUNG: Das ist vorerst meine Vermutung bzw. Befürchtung (resultierend aus langer Erfahrung), noch keine verifizierte Tatsache.
Das Thema Simulation/Debuggen können wir auch mit unserem ACCONtrol angehen. Dort habe ich wenigstens etwas Einflussmöglichkeiten auf die Features die dort eingebaut werden :wink: Vom Prinzip her ist ACCONtrol eine CPU416 auf dem PC. Ist ebenfalls portabel geschrieben und existiert in verschiedenen Varianten, von der Simulation bis hin zur harten Echtzeitlösung basierend auf CEWin von Kuka. Auch die Debug-Möglichkeiten (Status Bausteine) sind bei uns im Hause vorhanden und müssen somit nicht erneut erfunden bzw. analysiert und entwickelt werden.
Soweit zu den Dingen die wir beisteuern können.
Aus Erfahrungen mit anderen Gemeinschaftsentwicklungen bin ich der Meinung, dass wir uns vor einem richtigen Projektstart über die rechtliche Seite einig sein müssen. Wenn nachher ein gutes Projekt deshalb scheitert, wel sich jeder dabei etwas anderes gedacht hat, wäre das schade. 
Als nächstes kommt dann die technische Definition. Was soll das Ganz umfassen, welchen Sprachumfang, was ist überhaupt auf S7 umsetzbar (Anm.: printf über Textausgabe z.B. an CP340 o.ä. :lol: :?: ). Für die Realisierung bevorzuge ich eindeutig C++. Die Kapselung und Wiederverwertbarkeit der Klassen (wenn einigermassen sauber implementiert) ist ein klarer Vorteil für die Aufgabe.


----------



## seeba (27 Januar 2006)

Rainer Hönle schrieb:
			
		

> (Anm.: printf über Textausgabe z.B. an CP340 o.ä. :lol: :?: )


Dazu müsste man bei printf aber schon mindestens 2 Überladungen vorsehen.

```
printf(int cpaddr, string text)
```


----------



## Barnee (27 Januar 2006)

Moin allseits

War ne kurze Nacht für mich. Wollte heute morgen gar nicht so recht entscheiden, ob ich meine Augenlider heben sollte oder nicht. war fast eine Nor/Nand/Xor-Entscheidung   

Rainer hat den wichtigen Punkt schon angesprochen:



			
				Rainer Hönle schrieb:
			
		

> Aus Erfahrungen mit anderen Gemeinschaftsentwicklungen bin ich der Meinung, dass wir uns vor einem richtigen Projektstart über die rechtliche Seite einig sein müssen. Wenn nachher ein gutes Projekt deshalb scheitert, wel sich jeder dabei etwas anderes gedacht hat, wäre das schade.



Wir sollten versuchen ein persönliches Treffen zu arrangieren, zumindest aber mal eine Audiokonferenz, des wegen nochmals meine Frage in die Runde, ob ihr schon was wegen Skype unternommen habt? Technnische Fragen klären wir im Anschluß daran.

Als Initiator dieser Runde, gestatte ich mir vorläufig den Hut aufzuhaben, bin aber gerne bereit, den auch wieder abzugeben, wenn dies ein anderer machen möchte. Ich überlasse dies einer gemeinschaftlichen Entscheidung. Aber ich denke mir, jemand sollte die Fäden in einer Hand halten, sonst geht das Projekt den Bach herunter, bevor es richtig gestartet ist. Was aber nicht heißen soll, das niemand mehr seinen Gedanken freien Lauf lassen sollte. Auch in einem Team gibt es gewisse Spielregeln, sonst kann man sich nicht in Arbeitsgruppen aufteilen. Ich würde daher vorschlagen, daß wir/ich bestimmte Kernfragen formuliere und dann darüber abstimmen.

Deswegen stelle ich hier schon mal die ersten Kernfrage:

Seit ihr damit einverstanden, dass ich vorerst die Projektführung machen soll? Ja/Nein?

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

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

Bezüglich der rechtlichen Situation würde ich gerne jeden bitten, sich hierüber einmal Gedanken zumachen und sich dazu zu äußern. Ich werde gleiche einen anderen Thread "rechtliche Klärung" aufmachen, wo ihr eure Gedanken nur zu diesem Thema reinschreiben solltet.

Und diesen Punkt sollten wir wirklich zuerst klären.

Gruß Barnee


----------



## seeba (27 Januar 2006)

Barnee schrieb:
			
		

> Seit ihr damit einverstanden, dass ich vorerst die Projektführung machen soll? Ja/Nein?


Ja!


			
				Barnee schrieb:
			
		

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


Ja!


			
				Barnee schrieb:
			
		

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


Ja!


----------



## Rainer Hönle (27 Januar 2006)

Barnee schrieb:
			
		

> Seit ihr damit einverstanden, dass ich vorerst die Projektführung machen soll? Ja/Nein?


Ja.



			
				Barnee schrieb:
			
		

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


Ja. 



			
				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.


----------



## Speedy (27 Januar 2006)

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 (27 Januar 2006)

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


----------



## Jochen Kühner (29 Januar 2006)

*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!


----------



## seeba (29 Januar 2006)

*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?


----------



## Barnee (31 Januar 2006)

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



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


----------



## Rainer Hönle (1 Februar 2006)

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.


----------



## Barnee (1 Februar 2006)

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:


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


----------



## Rainer Hönle (1 Februar 2006)

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.


----------



## Barnee (1 Februar 2006)

Hallo Rainer + @All



			
				Rainer Hönle schrieb:
			
		

> So ein sauber geklammerter Ausdruck schockt mich noch nicht.


Mich auch nicht     
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:

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


----------



## Zottel (7 März 2007)

seeba schrieb:


> Dazu müsste man bei printf aber schon mindestens 2 Überladungen vorsehen.
> 
> ```
> 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().


----------



## matthiasd:-m (9 März 2007)

*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


----------



## zotos (9 März 2007)

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.


----------



## matthiasd:-m (9 März 2007)

*habe verstanden ...ä*

Hi Zotos,

Danke für den Hinweis

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

Grüße 

matthias


----------



## pvbrowser (18 März 2007)

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 ?


----------



## Zottel (18 März 2007)

pvbrowser schrieb:


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


----------



## Zottel (18 März 2007)

zotos schrieb:


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


----------



## zotos (18 März 2007)

Zottel schrieb:


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


----------



## adkesv (17 Oktober 2015)

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


----------

