Writing a ST compiler

[JesperMP]

As I understad it each "case element" consists of a value (or value list), an ":", and a statement (or statements). Each statement must end with an ";".
So your problem is that there can be several ";" because there can be several statements for each case ?

I think your code has to memorise that a CASE is active, so if an ":" (and no ":=") is encountered AFTER an ";" (and no END_CASE yet), then it is the start of a new case element.

 

[nettogrisen]

I just did a quick search on Lex and Yacc and it looks like you add tokens such as ":" or ":=", so destinguishing between the two shouldn't be a problem

http://memphis.compilertools.net/interpreter.html

 

[LadderLogic]

The difficulty is that other languages have a key word that indicates the end of the case element. C uses the word break. Pascal uses begin and end. ST doesn't use anything to indicate the end of a case element.

Structured text CASE OF statements are a pain in the a$$. There are no similar languages that I can use as an example.

Visual Basic comes to mind.

Select Case a
    Case 1
        b = 4
        c = b + 5
    Case 2, 3, 5
        b = 6
    Case Else
        b = c - 1
End Select

BTW, I recently began to play with Red Lion G3 series HMI and their scripting language looks quite nice. Very similar to good old C, with strings handling much simplified. No pointers though, which, of course will make a lot of people unhappy.

 

[nettogrisen]

It does look similar but Basic is newline terminated, which makes it easier to destinguish between the cases, (not to state the obvious "Case" keyword)

Pointers would be a very nice feature, but would be very tricky to implement.

 

[Peter Nachtwey]

Can't you determine a new case by looking for ":"? (which would end the previous case)

That is part of the problem. The parser sees the integer for the case number and thinks it is starting a new expression and then it sees the ':' and that doesn't belong.

Other languages have problems with the 'dangling' IF ELSE. This occurs when
IF expr stmt IF expr stmt ELSE stmt
Does the else go with the first or second IF. ST makes this easy because there is an END_IF which makes it clear. I am suffering the from the same problem but now it is a CASE OF statement.

Couldn't you "just" extend the IEC spec. and implement some of the features that it lacks?

No, I am kind of a purist.

Wouldn't it still conform to the IEC spec?

No.


The Yacc and Bison parser generators are 'standard' tools but they aren't very good. I previous compiler writer didn't use Yacc or Bison and he rolled his own parser just to avoid these problems.



My IL will have the ability to do more complex expressions since it will borrow from the ST compiler. IL doesn't say how indirect address should be implemented. These kind of things drive me nuts as it is such an obvious oversight. So I am going to allow ST expressions as the operand.

      LD     A[I].COUNT

Doing all the indirect addressing in IL would be messy. I see this as one of the biggest weaknesses of Siemens' STL. Too much time/effort is spent on how to do the indirect addressing.

I will write again when I have more progress. The point is that the key words like END_CASE, END_IF and begin and end in Pascal make life much easier for the compiler writer and without them it is hard to define a grammar that is easy to parse.

 

[Thomas_v2]

In the Siemens SCL documentation is a SCL formal language description. The rules are shown in graphical diagrams, but it's relative easy to translate them into EBNF.

One difference from Siemens SCL to other ST implementations is the extra semicolon you have to add in SCL after some ending keywords.

 

[Peter Nachtwey]

In the Siemens SCL documentation is a SCL formal language description. The rules are shown in graphical diagrams, but it's relative easy to translate them into EBNF.

I have the IEC specfication. I can copy and paste it into my yacc file but then I have to translate it into yacc format which is different than EBNF. There is another parser generate named ANTLR that uses a format closer to EBNF.

The nice thing about EBNF is that it is easy to specify if items like labels are optional and whether statements or case_elements can be used multiple times. ANTLR makes this easier too.

 

[Peter Nachtwey]

I got past my CASE OF END_CASE problem the right way. I have now got all the looping and flow control stuff done. I am starting to get the hang of it. For a while I was thinking about taking a class but the class doesn't go as far as I have already gone so that won't help.

Right now my compiler is generating an IL like code but my code is stack based and only loads and stores have variables. The other instructions work with the variables on the stack that have been previous loaded. Out putting IL like instructions makes it easy to see if the generated code is correct.

FOR I:=0 TO 9 BY C+4 DO A:=A+1; END_FOR

        LD      0
        JMP     L001
L000:
        LD      A
        LD      1
        ADD
        ST      A
        LD      I
        LD      C
        LD      4
        ADD
        ADD
L001:   ST      I
        LD      9
        LE
        JMPC    L000

Right now my variables are simple one letter variables. I need to enhance that to support multi character variables with all the different data types supported.

There is nothing in the IEC specification that says how one does indirect addressing in LD.

 

[Peter Nachtwey]

Where does one declare data types with TYPE .. END_TYPE

I am looking at the 61131-3 ST specification. It is clear how user defined data types are declared but it isn't clear where they are declared. From what I have seen the TYPE.. END_TYPE can't be used anywere within a program, FB,FN etc.

I do see mentions of a declaring user types in a library but this is stupid limitation.
Where do other implementations declare user defined data types?

 

[JesperMP]

For Siemens SCL, UDTs are defined outside the DBs or FBs where the UDTs are used.
The compiler has to know the UDTs before the usage in DBs or FBs. So the order of compiling the blocks must be arranged by the programmer to ensure this.
UDTs must be the very first that is compiled, then UDTs that are derived from other UDTs, then shared DBs, then FBs, then FBs with other FBs embedded as multiple instance, then FCs, then OBs.
edit: Which of course is too generic to apply always, an FB can call an FC, and the other way round. It is the programmer that must make sure that the order of compiling is correct.

 

[nettogrisen]

I don't have a copy of the IEC 61131-3 spec., so I don't know if this is useful in any way, but it descibes a little about UDT declaration

http://www.documentation.emersonpro...pplication_notes-tech._briefs/d301332x012.pdf

 

[L D[AR2P#0.0]]

Here's the Twincat version:

 

[Noli2]

http://www.pc-control.net/pdf/042011/pcc_0411_interview_twincat3_e.pdf

TwinCAT 3 from Beckhoff might do the job?

I don't have experience with version 3, but version 2 already has lots of power when programming complex machines.

By the way, my collegue already wrote a ST compiler more than 10 years ago

 

[Thomas_v2]

Try searching google "iec 61131-3 draft" and you will find a word document with the latest specification.

But I think the formal language descriptions in the appendices are not complete. For example the production for unsigned_integer is missing.

I've found an open source project which implementes ST and IL. It uses flex/yacc to generate the scanner/parser.
It's a good starting point:
http://sourceforge.net/projects/mat/

The flex/yacc files are in this folder:
http://mat.cvs.sourceforge.net/viewvc/mat/logic/iec/stage1_2/

 

[RocketTester]

I know nothing of writing compilers, but offer a few random thoughts:

1. Matlab has an ST generator (for Contrologix and TwinCAT), which is sort of the reverse problem.

2. Beckhoff's new TwinCAT 3 allows programming the PLC in C. Of course "C" is a minimal definition, so not sure what theirs will be. One of their long-time engineers promotes OOP on automation sites, so maybe a C++ or C# type flavor. I would have preferred the simpler syntax of Visual Basic, but professional programmers seem to love obsfuscation. This suggests that ST may have run out of legs. Still, I can understand a desire to program your Delta controllers in ST (we have a few).