Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 13

Thema: Themen zum Preprozessor

  1. #1
    Registriert seit
    18.12.2005
    Beiträge
    71
    Danke
    0
    Erhielt 1 Danke für 1 Beitrag

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Ich starte hiermit den Thread für Themen rund um den Preprozessor.

    Gruß Barnee
    Zitieren Zitieren Themen zum Preprozessor  

  2. #2
    Barnee ist offline Benutzer
    Themenstarter
    Registriert seit
    18.12.2005
    Beiträge
    71
    Danke
    0
    Erhielt 1 Danke für 1 Beitrag

    Standard

    Unabhängig davon ob es sich um den PP oder Parser handelt, gilt es einmal festzulegen, mit welchem Speichermodell wir arbeiten wollen. Legen wir entsprechend den Urzeiten Metafiles an, oder allocieren wir den benötigten Speicher dynamisch?

    Ich denke, da zu diesen Zeiten der Speicher keine Kostenfrage mehr ist, sollten wir vorzugsweise mit dynamisch angelegtem Speicher hantieren. M.E. ist bei einem S7-Projekt nicht zu erwarten, das dies die Grenzen des zur Verfügung stehenden Speichers sprengen würde. Dies könnte u.U. jedoch auftreten, wenn jemand alle Bausteine eines S7-Projektes in einem C-File abspeichert. Aber auch dieses Problem lässt sich lösen, da doch die Bausteine innerhalb eines C-Projektes auch jeweils als abgeschlossene Einheiten abzugrenzen sind, d.h. der Compiler arbeitet grundsätzlich immer nur einen Baustein ab, der dann nach der Fertigstellung auf die HD geschrieben werden kann, um anschließend den belegten Speicher wieder freizugeben. Bei geschickter Handhabung kann somit eine Fraktionierung des Speicher sicher verhindert werden, was die Gefahr eines Compilerkollapses ausschließt.

    Der Parser liest somit die Bausteine immer als ganzes in den Speicher ein. Hier ist zunächst eine Schwierigkeit vorhanden. Wenn man davon ausgeht, dass eine C-Datei immer nur einen Baustein enthalten würde, wäre diese Schwierigkeit nicht vorhanden, da man aus der Größe der Quelldatei den benötigten Speicher leicht bestimmen kann. Doch was ist, wenn z.B. 10 Bausteine in einer C-Quelle vorhanden sind?

    Eine Möglichkeit, die mir gerade einfällt, wäre, erst einmal eine Annahme über den benötigten Speicher zu machen. In den reservierten Speicher wird zunächst der entsprechende Anteil des C-Quelltextes eingelesen. Jetzt prüft der PP die geschweiften Klammerpaare ab, auf eine geöffnete Klammer kann entweder eine schließende Klammer oder eine weitere öffnende Klammer folgen usw.usf. Man zählt die Klammern, eine öffnende Klammer inkrementiert und eine schließende Klammer dekrementiert. Wird dabei von 1 auf 0 herunter gezählt, ist das Ende der Funktion (FC oder FB) erreicht! Wird die "0" vor Ende des reservierten Speichers erreicht, dann befindet sich ein kompletter Baustein im Speicher, ist dass jedoch nicht der Fall, dann muss ein weiterer Speicher mit angenommener Größe reserviert werden und der nächste Teil des C-Quelltextes wird eingelesen. Die Zählung der Klammerpaare wird dann fortgesetzt. Wird jetzt der Vorgang von 1 nach 0 ermittelt, dann ist die Größe des insgesamt benötigten Speichers bekannt. Konnte auch dieses Mal das Ende des Bausteins nicht ermittelt werden, dann wird der Vorgang durch Einrichtung eines weiteren Speichers wiederholt. Ich hoffe nicht, dass jemand einen so großen Baustein geschrieben hat, der 750.000 Zeilen enthält, denn dann wären etwa 50 MB Speicher erforderlich.

    Wurde bisher nur EIN Speicherbereich reserviert, so befindet sich der gesamte Baustein in einem zusammenhängenden Speicherbereich, so dass keine weiteren Maßnahmen in diesem Zusammenhang erforderlich sind. Wurde dagegen der Baustein in mehreren Abschnitten eingelesen, so sollte ein zusammenhängender Speicher mit der entsprechenden Größe reserviert werden. In diesen Speicher werden dann die Teilquellen lückenlos verschoben, danach werden die ursprünglich reservierten Teilbereich wieder freigegeben.

    So, das war's erst einmal. Ich stelle das hier zur Diskussion. Vielleicht weiss jemand eine bessere Möglichkeit?

    Gruß Barnee
    Zitieren Zitieren C-Quelltexte einlesen  

  3. #3
    Registriert seit
    11.04.2005
    Beiträge
    13
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Standard

    Hallo zusammen,

    gibt es irgendwelche Sachen die der Preprozessor bei unterschiedlichen CPUs berücksichtigen muss. Kennt z.B. die S7-200 float und double. Sind die Zahlenbereiche bei allen CPUs identisch.

    Welche CPUs wollen wir überhaupt unterstützen?

    Gruß Speedy

  4. #4
    Registriert seit
    27.10.2005
    Ort
    Schwäbisch Gmünd
    Beiträge
    5.224
    Danke
    630
    Erhielt 955 Danke für 769 Beiträge

    Standard

    Die 200er ist so ein bisschen ein Sonerthema bei Siemens. Kommt ursprünglich von ti (so heißt es). Hat fast nichts mit der 300er und 400er zu tun, außer gewisse Gemeinsamkeiten bei der Kommunikation. Mir wäre es arg Recht, wenn wir uns für den Anfang auf die "großen" konzentrieren könnten.
    Rainer Hönle
    DELTA LOGIC GmbH

    Ein Computer kann das menschliche Gehirn nicht ersetzen. Engstirnigkeit kann unmöglich simuliert werden. (Gerd W. Heyse)

  5. #5
    Registriert seit
    17.06.2004
    Ort
    Offenau
    Beiträge
    3.745
    Danke
    209
    Erhielt 421 Danke für 338 Beiträge

    Standard

    es ist ja auch wichtig für uns welche SFB's und SFC's von der jeweiligen Cpu unterstützt werden...

    Gut am anfang vieleicht noch nicht, aber falls wird dann eine lib zur stringverarbeitung einbauen muss ja klar sein ob z.b. der sfc20 (blockmove vorhanden ist oder nicht)
    ---------------------------------------------
    Jochen Kühner
    https://github.com/jogibear9988/DotN...ToolBoxLibrary - Bibliothek zur Kommunikation mit PLCs und zum öffnen von Step 5/7 Projekten
    Zitieren Zitieren SFB's/SFC's  

  6. #6
    Registriert seit
    27.10.2005
    Ort
    Schwäbisch Gmünd
    Beiträge
    5.224
    Danke
    630
    Erhielt 955 Danke für 769 Beiträge

    Standard

    Da müssen wir halt Codegenerierungsoptionen ähnlich Prozessor im VirtualStudio einbauen, damit die Steureungseigenheiten möglichst optimal unterstützt werden. Ineffizienten Code gibt es bereits genügend!
    Rainer Hönle
    DELTA LOGIC GmbH

    Ein Computer kann das menschliche Gehirn nicht ersetzen. Engstirnigkeit kann unmöglich simuliert werden. (Gerd W. Heyse)

  7. #7
    Barnee ist offline Benutzer
    Themenstarter
    Registriert seit
    18.12.2005
    Beiträge
    71
    Danke
    0
    Erhielt 1 Danke für 1 Beitrag

    Standard

    Hallo @All

    Vorab mal etwas grundsätzliches, ich verstehe unter einem PP einen Automaten, der sich ausschließlich mit Formalien beschäftigt. Vielleicht kann man einen PP aus einer Opensource-Quelle übernehmen? Ich weiß es nicht! Nach meiner Ansicht macht ein PP eine mögliche C-Quelle nur handlicher, d.h., um es noch einmal auf die m.E. wichtigsten Punkten eines PP zu konzentrieren:
    -- Eine gut strukturierte C-Quelle enthält viele Leerzeichen/Tabs für Einrückungen, die für den eigentlichen Compiliervorgang nicht erforderlich sind. Diese gilt es zu beseitigen.
    -- Eine gut dokumentierte C-Quelle enthält viele Kommentare, die entweder in einer Zeile stehen oder über mehrere Zeilen sich erstrecken können. Auch diese Kommentare sind für den eigentlichen Compiliervorgang nicht erforderlich sind. Diese gilt es zu beseitigen.
    -- Mit "#define" können Makros verabredet werden. Diese Makros müssen vor der Ausführung des Parsers substituiert werden.
    -- Funktionen, die in Libraries angesprochen werden, werden in Header-Files durch ihren Prototypen repräsentiert. Auch diese (#include)-Header-Files müssen mit eingelesen werden und müssen vorerst durch den PP zu ähnlichen Bedingungen wie die eigentliche C-Quelle behandelt werden (Achtung: Compiler-Direktiven).
    -- Es müssen alle Variablen erfaßt und (Compiler-interne) Referenzen darauf abgebildet werden. Aber anders als in einem wirklichen Compilat für einen uP, beziehen sich diese Referenzen, ausschließlich auf Variablen, die für die Schnittstellen-Parameter eines S7-FCs oder S7-FBs verwendet werden, also Var_input, Var_ouput, Var_inout, Var_temp und Var.
    -- Es werden Klammerungen untersucht, d.h. die in C möglichen Klammerungen müssen immer zu einem formal abgeschlossenen Ausdruck führen. (Ich will das hier an dieser Stelle nicht weiter vertiefen, weil ich zu diesem Teil zu einem späteren Zeitpunkt noch meine Anmerkungen ausführen möchte.)

    Wenn der PP die v.g. Punkte abgearbeitet hat, was nach m.E. in einem Durchgang (Pass) erfolgen sollte, dann steht eine Zwischendatei zur Verfügung, die nur formal bereinigt ist und noch keine spezifischen Aussagen zu den im C-Quelltext enthaltenen C-Konstruktionen festgelegt hat. IMHO verhält sich der PP bis zu diesem Punkt (fast) völlig neutral, was das Ziel des später fertiggestellten Compilats betrifft. Ich lasse mich aber gerne belehren, wenn anderweitige Erkenntnisse zu einem PP vorliegen.

    Zitat Zitat von Speedy
    Hallo zusammen,

    gibt es irgendwelche Sachen die der Preprozessor bei unterschiedlichen CPUs berücksichtigen muss. Kennt z.B. die S7-200 float und double. Sind die Zahlenbereiche bei allen CPUs identisch.

    Welche CPUs wollen wir überhaupt unterstützen?

    Gruß Speedy
    Zitat Zitat von Rainer Hönle
    Die 200er ist so ein bisschen ein Sonerthema bei Siemens. Kommt ursprünglich von ti (so heißt es). Hat fast nichts mit der 300er und 400er zu tun, außer gewisse Gemeinsamkeiten bei der Kommunikation. Mir wäre es arg Recht, wenn wir uns für den Anfang auf die "großen" konzentrieren könnten.
    Wie oben schon gesagt, ist es nach m.E. für den PP (gilt nur für den PP nicht für den Parser) völlig Schnurz, welche CPU am Ende mit dem fertigen Compilat beglückt werden soll. Bei S5-CPUs wäre es schon wichtig zu wissen gewesen, welche "Onboard"-Funktionen vorhanden sind, da gab es zwischen 115, 135 und 155 schon reichlich Unterschiede. Aber gottlob stellt sich für uns die S5-Frage nicht. Bei S7-300 und S7-400 wird es sicher auch Unterschiede geben, diese Berücksichtigung kann man sicher durch "#include" spezifisch bekannt geben. Grundsätzlich könnte ich mir den Compiler auch für die Anwendung bei einer S7-200 vorstellen, ob das jedoch Sinn macht, entzieht sich z.Zt. meiner Erkenntnis, wobei ich dann aber eher den Eindruck habe, das wir in einem solchem Falle mit Kanonen auf Spatzen schießen.

    Nach meinem Wissensstand (man mag mich widerlegen) verfügen die CPUs der S7-300/400 ausschließlich über eine Gleitkommaverarbeitung mit Single-Precision (4 Byte), Double-Precision (8 Byte) würde damit schon mal ausscheiden. Eine Verarbeitung mit höherer Genauigkeit wäre jedoch möglich, wenn man die Parameterübergabe auf der Basis des ANY-Pointers gestalten würde und eigene Funktionen hierfür schaffen würde - Zukunftsmusik? - vielleicht, eine Wertausgabe wäre über OPC an externe Rechner möglich.

    Zitat Zitat von Jochen Kühner
    es ist ja auch wichtig für uns welche SFB's und SFC's von der jeweiligen Cpu unterstützt werden...

    Gut am anfang vieleicht noch nicht, aber falls wird dann eine lib zur stringverarbeitung einbauen muss ja klar sein ob z.b. der sfc20 (blockmove vorhanden ist oder nicht)
    Siehe oben. SFCs und SFBs sind wie der Name schon sagt Funktionen und Funktionsbausteine des S7-Systems. Der Zugriff zu diesen Funktionen (ich fasse das mal zusammen, mir ist diese Siemens-Terminologie etwas lästig, weil der Unterschied ja nur Siemens-spezifisch ist) erfolgt aus der Sicht unseres C-Compilers wie auf eine gewöhnliche Library, d.h. wir werden für diese SFCs und SFBs C-spezifische Headerfiles erstellen, die dann durch unseren C-Compiler berücksichtigt werden.

    Zitat Zitat von Rainer Hönle
    Da müssen wir halt Codegenerierungsoptionen ähnlich Prozessor im VirtualStudio einbauen, damit die Steureungseigenheiten möglichst optimal unterstützt werden. Ineffizienten Code gibt es bereits genügend!
    Ich kenne denn PP vom VirtualStudio nicht, vielleicht kann Rainer uns da mal etwas mehr von vorstellen.

    Beispiele von ineffizienten Code muss ich mir täglich anschauen, das was z.B. SCL an AWL zusammenbastelt, ist wirklich katastrophal. Wer CFC kennt, weiss, dass man mit CFC FBs basteln kann (ich sage bewusst basteln). Diese Bausteine kann man in SCL übersetzen. Die Sicht in solche Bausteine stellt mir stets die Haare senkrecht auf. Mit einer Nachbehandlung in SCL verliert der Baustein damit seinen Bezug zum CFC (was mir aber egal ist) aber auch gleichzeitig etwa 50% seines überflüssigen Codes. Eine weitere Nachbehandlung in AWL bringt nochmals eine Reduzierung um beachtliche Prozentzahlen. Hier mal ein SCL-Beispiel zum Vergleich von zwei 16-Bit-Integern (ich beschränke mich nur auf die Darstellung des Wesentlichen):

    Code:
    gt := IN1 >  IN2;
    ge := IN1 >= IN2;
    eq := IN1 == IN2;
    le &#58;= IN1 <= IN2;
    lt &#58;= IN1 <  IN2;
    Sieht eigentlich elegant aus, aber das gibt der SCL-Übersetzer als AWL-Code aus:
    Code:
    L    #IN1
    L    #IN2
    >I
    =    #gt
    L    #IN1
    L    #IN2
    >=I
    =    #ge
    L    #IN1
    L    #IN2
    ==I
    =    #eq
    L    #IN1
    L    #IN2
    <=I
    =    #le
    L    #IN1
    L    #IN2
    <I
    =    #lt
    Nicht optimal!!!!!Und das wäre optimal:
    Code:
    L    #IN1
    L    #IN2
    >I
    =    #gt
    >=I
    =    #ge
    ==I
    =    #eq
    <=I
    =    #le
    <I
    =    #lt
    Gruß Barnee

  8. #8
    Registriert seit
    27.10.2005
    Ort
    Schwäbisch Gmünd
    Beiträge
    5.224
    Danke
    630
    Erhielt 955 Danke für 769 Beiträge

    Standard

    Zitat Zitat von Barnee
    Nicht optimal!!!!!Und das wäre optimal:
    Code:
    L    #IN1
    L    #IN2
    >I
    =    #gt
    >=I
    =    #ge
    ==I
    =    #eq
    <=I
    =    #le
    <I
    =    #lt
    Das automatisch hinzubekommen ist nicht nur optimal sondern genial. Das muss der Codegenerierer sämtliche Registerinhalte "im Kopf" haben, dann geht das. Ist anzustreben aber nicht einfach. Die heutigen Compiler machen hier manches auch in mehreren Durchläufen nacheinander.
    Anm.: Ich nenne die Entwicklungsumgebung meines Freundes Bill (the Gates) liebevoll VirtualStudio. Weil Visual ist es m.E. noch nicht ganz.
    Rainer Hönle
    DELTA LOGIC GmbH

    Ein Computer kann das menschliche Gehirn nicht ersetzen. Engstirnigkeit kann unmöglich simuliert werden. (Gerd W. Heyse)

  9. #9
    Registriert seit
    11.04.2005
    Beiträge
    13
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Standard

    Hallo zusammen,

    habe mich mal so im Netz umgeschaut ob man etwas findet was man als Ausgangspunkt nehmen könnte. Bin dabei auf einen ‚C and T preprocessor, and integrated lexer’ gestoßen.

    Sicher müsste man noch ein paar Änderungen und einen ‚Frontend’ machen aber dass sollte nicht so viel arbeit sein.

    Wünsche Euch noch ein schönes Wochenende.

    Gruß Speedy
    Angehängte Dateien Angehängte Dateien

  10. #10
    Barnee ist offline Benutzer
    Themenstarter
    Registriert seit
    18.12.2005
    Beiträge
    71
    Danke
    0
    Erhielt 1 Danke für 1 Beitrag

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hallo Speedy

    Danke für den Tip. Ich hatte gestern auch schon mal im Netz geschaut und verschiedene Links gefunden, doch der von dir gefundene war (leider ) nicht dabei. Ich habe schon mal einen kurzen Blick in den Quelltext geworfen und wie es scheint, könnte man darauf aufsetzen, was uns viiiiiieeeeel Arbeit ersparen würde.

    Meine Idee ist nach wie vor, nicht alles sequentiell zu entwickeln, sondern in verschiedenen Arbeitsbereichen, so weit es geht, parallel zu arbeiten. Mit meinem Einstieg in die Diskussion um den PP hatte ich beabsichtigt, unser Ziel etwas näher zu spezifizieren, da doch die Meinungen um das, was ein PP machen sollte, etwas quer Beet gehen.

    Bei weiterem Nachdenken bin ich nun an den Punkt angekommen, dass es jetzt schon sehr wichtig ist, zuvor den Rahmen, der die Notwendigkeiten für unser Projekt einschließen soll, näher zu definieren. Als ich meine ersten Gedanken zu einzelnen Themen niederschrieb, war ich noch nicht soweit, zumal man sich naturgemäß lieber mit "konkreten" Dingen beschäftigt als über Abstraktionen nachzudenken. Ich habe jetzt ein neues Ziel ausgemacht, von dem ich der Meinung bin, das wir das vorrangig angehen sollten, ich werde in dem Thread "Gemeinsamkeiten C <-> Step7" http://www.sps-forum.de/phpBB2/viewtopic.php?t=6652 beginnen, meine Gedankengänge hierzu nieder zu schreiben.

    Gruß Barnee
    Und der Weg zur Hölle ist mit guten Vorsätzen gepflastert......

Ähnliche Themen

  1. Themen schliessen
    Von Brro87 im Forum Stammtisch
    Antworten: 15
    Letzter Beitrag: 14.01.2009, 08:47
  2. Die lustigsten Themen 2008
    Von diabolo150973 im Forum Stammtisch
    Antworten: 17
    Letzter Beitrag: 30.12.2008, 17:00
  3. preprozessor direktiven auf B&R
    Von Hannes im Forum Sonstige Steuerungen
    Antworten: 12
    Letzter Beitrag: 24.07.2007, 14:29
  4. Themen zum Parser
    Von Barnee im Forum Hochsprachen - OPC
    Antworten: 1
    Letzter Beitrag: 01.02.2006, 23:49

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •