TIA TIA Compiler

Ich weiß, die Hintergedanke meiner Frage ist nur, ob der Compiler das erkennen könnte, weil er theoretisch die Möglichkeit dazu hätte.
Wie soll der Compiler merken können dass du die AWL Zeilen nicht ausführen willst ?
Computer Sprachen sind eine eksakte Weise den Computer zu erzählen was es machen soll.
Wenn du "=" schreibst, ist wie der Compiler oder Interpreter zu erklären, "übergebe die VKE an die Variabel".
Die Gedanken muss von der Programmierer gemacht werden.

edit: in diesen Fall kan es sein, der Compiler interpretiert es als
Lade ein FALSE ins VKE Stack, dann übertrag unterste VKE Stack zum Variabel.
Oder es optimiert die Code ins
Setze den Variabel FALSE.
Den funktionelle Ergebniss ist dieselbe.
 
Zuletzt bearbeitet:
Wie meinst du das?Wenn du jede Undverknüpfung abrechen kannst oder nicht dann summiert sich das ja auf das ganze Programm hoch.
Mal liest er 10 Unds mal ein Und Und.darum entstehen ja durch diese Spagetti Code Programmierung mit den Sprüngen genau diese Laufzeitunterschiede.Das ist ja nichts anderes.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Mit einem fixen false: Keine
Wenn du mit einem konstanten False Code nicht aufrufbar machen möchtest, geht das bei einer Zuweisung nicht.

Dann muss du die betroffenen Programmzeilen komplett löschen. Dann hast du es auch wirklich aus der Bearbeitung genommen.

Das was du da vor hast, funktioniert einfach nicht!
 
@JesperMP Du hast die Frage nicht verstanden.

Ich denke wir drehen uns hier um Kreis.

Fest steht anscheinend, dass beim Übersetzen keine logische Optimierung oder Überprüfung stattfindet. Alles andere hätte mich auch eher gewundert. Aber in anderen Sprachen wie z.B. C gibt es das. Dort kann ein Compiler erkennen, dass ein Programmteil aus logischer Sicht niemals ausgeführt werden kann und dementsprechend kompiliert, und ich meine jetzt keine Sprünge. Daher die Frage.
 
Noch eine Anmerkung zu MC7.
Auf 1200/1500er gibt es keinen MC7 Code.
Sondern MC7Plus.
Siehe auch:


Und da, zumindest in den 1200er, ein ARM verbaut ist, muss der MC7Plus-Code ja interpretiert, oder zur Laufzeit kompiliert werden.
 
Der Code wird ja durch den UND FALSE nicht deaktiviert.
Naja, wenn man jetzt einen Codebereich folgendermaßen "auskommentiert" könnte der Compiler schon bei der Übersetzung wissen, dass er diesen Bereich niemals ausführen muss und sich die Überprüfung dann auch sparen:

IF false THEN
//do something
END_IF;

Ob das jetzt der Fall ist weiß ich leider nicht.

Ich habe einen Kollegen, der in KOP ganz gerne das erste Element als "true" setzt, da dann das Netzwerk schöner formatiert wird. Über ein komplettes Programm kommen da dann natürlich viele "unnötige" Verknüpfungen zusammen, bei denen schon das VKE schon bei der Übersetzung klar ist. Wäre im Grunde schön, wenn der Compiler diese dann im übersetzten Code nicht mehr berücksichtigen würde.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Der Codesys-Compiler macht für manche Prozessoren solche Optimierungen (in FUP). Da werden Programmteile übersprungen, wenn ein AND nur noch FALSE ergeben kann. Da läuft das Programm aber meistens nicht in einer freien Task (wie OB1 bei Siemens) sondern in zeitgesteuerten zyklischen Task (wie Siemens OB3x) - und so erhält man da wieder gleich lange Zykluszeiten oder ein Problem, wenn dummerweise zufällig mal wenig übersprungen werden kann und die Ausführung dann länger dauert als das Aufrufintervall der Task. Bei Programmen in ST oder SCL sollte der Compiler solche "heimlichen" Optimierungen aber nicht machen. Da "optimiert" ja schon der Programmierer durch bedingte IF...THEN-Orgien ;)
 

Anhänge

  • Codesys_AND_opt.png
    Codesys_AND_opt.png
    22,7 KB · Aufrufe: 17
Wenn man aus Gründen der Zykluszeititoptimierung auf folgende Weise mit Zeitimpulsen arbeitet, wird der Code so intelligent kompiliert, dass nach der ersten fehlenden Bedingung abgebrochen wird?
Meines Wissens kann man nicht nach der ersten fehlenden Bedingung abbrechen, ohne durch Prüfen der folgenden Bedingungen festzustellen, ob man die Stelle mit der ersten fehlenden Bedingung schon erreicht hat. Denn es kommt darauf an, dass weitere Verknüpfungen das derzeitige (Zwischen-)Ergebnis nicht mehr verändern können.
Ja, ein Compiler könnte eine "komplizierte" logische Verküpfung so umsortieren/umschreiben, dass sich möglichst früh schon das Ergebnis der Verknüpfung abzeichnet.
Beispiele:
( x2 ODER x3 ) UND x1 -> x1 UND ( x2 ODER x3 ) . Ist x1 FALSE, so kann das GesamtErgebnis nicht TRUE werden.
oder
x2 UND x3 ODER x1 -> x1 ODER x2 UND x3 . Ist x1 TRUE, so kann das GesamtErgebnis nicht FALSE werden.
@PeterPan-35: Ich meine mit false keinen Eingang der ein false aufweist, sondern wirklich ein echtes false im Code. In anderen Programmiersprachen werden solche Konstrukte je nach Kompilereinstellung intelligent kompiliert. Daher frage ich nach. Bei Eingängen ist mir es schon klar, dass es nicht geht.
"Wirklich ein echtes false" = ?
Was wäre das? Die Konstante FALSE? Oder "x1 UND /x1" ? Oder "x1 XOR x1" ?
Selbstverständlich kann ein Compiler versehentlich eingebaute "Überflüssigkeiten" erkennen und vermeiden und alle erdenklichen AbkürzungsMöglichkeiten prüfen und einen Code produzieren, der zur AusführungsZeit nicht mehr tun muss, als unbedingt nötig.
Aber wo ist die Grenze, ab der man keine (nennenswerte) Einsparung sieht, die einen zusätzlichen Aufwand beim Compiler rechtfertigen würde?
Wie soll der Compiler entscheiden, ob er ein weiteres Kriterium für seine Entscheidung benötigt oder ob der Code lieber etwas kürzer sein soll mit weniger OptimierungsMöglichkeiten?

Ist es wirklich erstrebenswert, verschiedene Lösungswege vom Compiler ausarbeiten zu lassen, wenn man beim Betrachten des Status im angezeigten Lösungsweg den ursprünglich programmierten Lösungsweg nicht auf Anhieb wiedererkennen kann?

Ich finde, man sollte vom Compiler keine grossen Optimierungen erwarten und lieber das eigene Gehirn einschalten.

Übrigens hat mir in der Sprache C das Abbrechen von logischen Verknüpfungen, sobald das Ergebnis nicht mehr verändert werden kann, immer bestens gefallen. Nicht um ns oder µs einsparen zu können, sondern, um Abfragen, die unter bestimmten Bedingungen "auf die Schnauze fallen" können, nur bedingt auszuführen.
Heute ists ja ein Compler früher wars ein Interpreter meine ich.
Das halte ich für ein Gerücht. Kannst Du das belegen?
Was belegen?
Dass heute ein Compiler am Werk ist?
Oder, dass früher interpretiert wurde?
Ich würde pauschal beide Behauptungen bestätigen und vorsichtshalber darauf hinweisen, dass Ausnahmen die Regel bestätigen könnten.
Zumal ein Compiler natürlich auch dazu benutzt werden kann, eine Sprache zu erzeugen, die noch interpretiert werden muss.

Die Zeit, die ein Compiler für das Optimieren "verbrät", verbrät er während des Compilierens, nicht zur AusführungsZeit des Programms.

Auch gab es ( BASIC- ) Interpreter, die zur Laufzeit die Position von SprungZielen gesucht und sich die ermittelten ZielAdressen für die folgenden Ausführungen der Sprünge gemerkt haben, um das zeitraubende Suchen nicht wiederholen zu müssen.

In S5 war es so, dass der Editor vieles geprüft und manches Verbotene verhindert hat.
Ein Bisschen optimiert hat er auch: scheinbar absolute Sprünge hat er in platzsparende relative Sprünge umgewandelt, denn absolute Sprünge gab es in MC5 nicht, ausser in der Form von BausteinAufrufen. Letztere waren nicht wirklich absolute Sprünge. Die ZielAdressen wurden zur Laufzeit mit Hilfe einer Tabelle ermittelt.
 
IF false THEN
//do something
END_IF;
Das ist doch im Endeffekt eine bedingte Compilierung? Anweisungen, die zum Zeitpunkt des Compilierens steuern, ob bestimmte ProgrammBereiche compiliert oder ignoriert werden sollen.
Bei PLCs gibt es etwas Schlimmeres (bei Siemens, bei Fanuc, ...).
Das war mir so suspekt, dass ich es nie benutzt habe und von dem mir momentan nichtmal einfällt, wie es heisst.
 
Die Frage ist ja auch, ob der Compiler bei einem "unmöglichen UND" dann wenigstens noch die Zuweisung durchführt.

Grade in alten Anlagen (S7-Klassik) sehe ich es permanent, dass zu Beginn von OB1 dann (sinngemäß) steht:
M0.0 := M0.0 AND NOT M0.0
M0.1 := NOT M0.0
Das sind dann die "feste Null" und "feste Eins".
 
Zurück
Oben