1

     2

     3

     4

  IEC 61131-3 IL and ST compiler

     5

     6

     7

  The following compiler has been based on the

     8

  FINAL DRAFT - IEC 61131-3, 2nd Ed. (2001-12-10)

     9

    10

    11

  (c) 2003 Mario de Sousa

    12

    13

    14

    15

****************************************************************

    16

****************************************************************

    17

****************************************************************

    18

*********                                              *********

    19

*********                                              *********

    20

*********   O V E R A L L    A R C H I T E C T U R E   *********

    21

*********                                              *********

    22

*********                                              *********

    23

****************************************************************

    24

****************************************************************

    25

****************************************************************

    26

    27

 The compiler works in 4(+1) stages:

    28

 Stage 1   - Lexical analyser      - implemented with flex (iec.flex)

    29

 Stage 2   - Syntax parser         - implemented with bison (iec.y)

    30

 Stage 3   - Semantics analyser    - not yet implemented

    31

 Stage 4   - Code generator        - implemented in C++

    32

 Stage 4+1 - Binary code generator - gcc, javac, etc...

    33

    34

    35

 Data structures passed between stages, in global variables:

    36

 1->2   : tokens (int), and token values (char *)

    37

 2->1   : symbol tables (defined in symtable.hh)

    38

 2->3   : abstract syntax tree (tree of C++ classes, in absyntax.hh file)

    39

 3->4   : Same as 2->3

    40

 4->4+1 : file with program in c, java, etc...

    41

    42

    43

 The compiler works in several passes:

    44

 Pass 1: executes stages 1 and 2 simultaneously

    45

 Pass 2: executes stage 3

    46

 Pass 3: executes stage 4

    47

 Pass 4: executes stage 4+1

    48

    49

    50

 NOTE 1

    51

 ======

    52

 Note that stage 2 passes data back to stage 1. This is only

    53

possible because both stages are executed in the same pass.

    54

    55

    56

    57

 NOTE 2

    58

 ======

    59

  I (Mario) have a feeling that the abstract syntax may be

    60

considerably simplified without any drawbacks to semantic checking

    61

and code generation. I have nevertheless opted to keep as much 

    62

info as possible in the abstract syntax tree, in case it may become

    63

necessary further on.

    64

 Once we start coding the next stages (semantic checking and code

    65

generation) I will get a better understanding of what is required

    66

of the abstract syntax tree. At that stage I will be better

    67

positioned to make a more informed decision on how best to structure

    68

the abstract syntax tree.

    69

 For now, we play conservative and keep as much info as possible.

    70

    71

    72

    73

 NOTE 3

    74

 ======

    75

 It would be nice to get this parser integrated into the gcc

    76

group of compilers. We would then be able to compile our st/il

    77

programs directly into executable binaries, for all the processor

    78

architectures gcc currently supports.

    79

 The gcc compilers are divided into a frontend and backend. The

    80

data structure between these two stages is called the syntax

    81

tree. In essence, we would need to create a new frontend that

    82

would parse the st/il program and build the syntax tree.

    83

Unfortunately the gcc syntax tree is not very well documented,

    84

and doing semantic checking on this tree would probably be a

    85

nightmare.

    86

 We therefore chose to follow the same route as the gnat (ada 95)

    87

and cobol compilers, i.e. generate our own abstract syntax tree,

    88

do semantic checking on our tree, do whatever optimisation

    89

we can at this level on our own tree, and only then build

    90

the gcc syntax tree from our abstract syntax tree.

    91

 All this may still be integrated with the gcc backend to generate

    92

a new gnu compiler for the st and il programming languages.

    93

Since generating the gcc syntax tree will probably envolve some

    94

trial and error effort due to the sparseness of documentation,

    95

we chose to start off by coding a C++ code generator for

    96

our stage 4. We may later implement a gcc syntax tree generator

    97

as an alternative stage 4 process, and then integrate it with

    98

the gcc toplevel.c file (command line parsing, etc...).

    99

   100

   101

   102

****************************************************************

   103

****************************************************************

   104

****************************************************************

   105

*********                                              *********

   106

*********                                              *********

   107

*********               S T A G E      1               *********

   108

*********                                              *********

   109

*********                                              *********

   110

****************************************************************

   111

****************************************************************

   112

****************************************************************

   113

   114

   115

   116

Issue 1

   117

=======

   118

   119

 The syntax defines the common_character_representation as:

   120

<any printable character except '$', '"' or "'"> | <escape sequences>

   121

   122

 Flex includes the function print_char() that defines

   123

all printable characters portably (i.e. whatever character

   124

encoding is currently being used , ASCII, EBCDIC, etc...)

   125

Unfortunately, we cannot generate the definition of

   126

common_character_representation portably, since flex

   127

does not allow definition of sets by subtracting

   128

elements in one set from another set (Note how

   129

common_character_representation could be defined by

   130

subtracting '$' '"' and "'" from print_char() ).

   131

This means we must build up the defintion of

   132

common_character_representation using only set addition,

   133

which leaves us with the only choice of defining the

   134

characters non-portably...

   135

   136

 In short, the definition we use for common_character_representation

   137

only works for ASCII character encoding!

   138

   139

   140

   141

   142

Issue 2

   143

=======

   144

   145

We extend the IEC 61131-3 standard syntax to allow inclusion of 

   146

other files. The accepted syntax is:

   147

   148

   (*#include "<filename>" *)

   149

   150

Note how this would be ignored by other standard complient compilers 

   151

as a simple comment!

   152

   153

   154

   155

****************************************************************

   156

****************************************************************

   157

****************************************************************

   158

*********                                              *********

   159

*********                                              *********

   160

*********               S T A G E      2               *********

   161

*********                                              *********

   162

*********                                              *********

   163

****************************************************************

   164

****************************************************************

   165

****************************************************************

   166

   167

 Overall Comments

   168

 ================

   169

   170

   171

 Comment 1

   172

 ---------

   173

 We have augmented the syntax the specification defines to include

   174

restrictions defined in the semantics of the languages.

   175

   176

 This is required because the syntax cannot be parsed by a LALR(1)

   177

parser as it is presented in the specification. Many reduce/reduce

   178

and shift/reduce conflicts arise. This is mainly because the parser

   179

cannot discern how to reduce an identifier. Identifiers show up in

   180

many places in the syntax, and it is not entirely possible to

   181

figure out if the identifier is a variable_name, enumeration

   182

value, function block name, etc... only from the context in

   183

which it appears.

   184

   185

 A more detailed example of why we need symbol tables are

   186

the type definitions...  In definition of new types

   187

(section B 1.3.3) the parser needs to figure out the class of

   188

the new type being defined (enumerated, structure, array, etc...).

   189

This works well when the base classes are elementary types

   190

(or structures, enumeration, arrays, etc. thereof). It becomes

   191

confusing to the parser when the new_type is based on a previously

   192

user defined type.

   193

   194

TYPE

   195

  new_type_1 : INT := 99;

   196

  new_type_2 : new_type_1 := 100;

   197

END_TYPE

   198

   199

 When parsing new_type_1, the parser can figure out that the

   200

identifier new_type_1 is a simple_type_name, because it is

   201

based on a elementary type without structure, arrays, etc...

   202

 While parsing new_type_2, it becomes confused how to reduce

   203

the new_type_2 identifier, as it is based on the identifier

   204

new_type_1, of which it does not know the class (remember, at this

   205

stage new_type_1 is a simple identifier!).

   206

 We therefore need to keep track of the class of the user

   207

defined types as they are declared, so that the lexical analyser

   208

can tell the syntax parser what class the type belongs to. We

   209

cannot use the abstract syntax tree itself to search for the

   210

declaration of new_type_1 as we only get a handle to the root

   211

of the tree at the end of the parsing.

   212

   213

 We therefore maintain an independent and parallel table of symbols,

   214

that is filled as we come across the type delcarations in the code.

   215

Actually, we ended up also needing to store variable names in

   216

the symbol table. Since variable names come and go out of scope

   217

depending on what portion of code we are parsing, we sometimes

   218

need to remove the variable names from the symbol table.

   219

Since the ST and IL languages only have a single level of scope,

   220

I (Mario) found it easier to simply use a second symbol table for

   221

the variable names that is completely cleared when the parser

   222

reaches the end of a function (function block or program).

   223

   224

What I mean when I say that these languages have a single level

   225

of scope is that all variables used in a function (function block

   226

or program) must be declared inside that function (function block

   227

or program). Even global variables must be re-declared as EXTERN

   228

before a function may access them! This means that it is easy

   229

to simply load up the variable name symbol table when we start

   230

parsing a function (function block or program), and to clear it

   231

when we reach the end. Checking whether variables declared

   232

as EXTERN really exist inside a RESOURCE or a CONFIGURATION

   233

is left to stage 3 (semantic checking) where we can use the

   234

abstract tree itself to search for the variables (NOTE: semantic

   235

cheching at stage 3 has not yet been implemented, so we may yet

   236

end up using a symbol table too at that stage!).

   237

   238

 Due to the use of the symbol tables, and special identifier

   239

tokens depending on the type of identifier it had previously

   240

been declared in the code being parsed, the syntax was slightly

   241

changed regarding the definition of variable names, derived

   242

function names, etc... FROM for e.g.:

   243

variable_name: identifier;

   244

TO

   245

variable_name: variable_name_token;

   246

   247

 Flex first looks at the symbol tables when it finds an identifier,

   248

and returns the correct token corresponding to the identifier

   249

type in question. Only if the identifier is not currently stored

   250

in any symbol table, does flex return a simple identifier_token.

   251

   252

 This means that the declarations of variables, functions etc...

   253

were changed FROM:

   254

function_declaration: FUNCTION derived_function_name ...

   255

TO

   256

function_declaration: FUNCTION identifier ...

   257

since the initial definition of derived_function_name had been

   258

changed FROM

   259

derived_function_name: identifier;

   260

TO

   261

derived_function_name: derived_function_name_token;

   262

   263

   264

   265

   266

 Comment 2

   267

 ---------

   268

 Since the ST and IL languages share a lot of common syntax,

   269

I have decided to write a single parser to handle both languages

   270

simultaneously. This approach has the advantage that the user

   271

may mix the language used in the same file, as long as each function

   272

is written in a single lanuage.

   273

   274

 This approach also assumes that all the IL language operators are

   275

keywords, which means that it is not possible to define variables

   276

using names such as "LD", "ST", etc...

   277

Note that the spec does not consider these operators to be keywords,

   278

so it means that they should be available for variable names! On the

   279

other hand, all implementations of the ST and IL languages seems to

   280

treat them as keywords, so there is not much harm in doing the same.

   281

   282

 If it ever becomes necessary to allow variables with names of IL 

   283

operators, either the syntax will have to be augmented, or we can 

   284

brake up the parser in two: one for ST and another for IL.

   285

   286

   287

   288

/********************************/

   289

/* B 1.3.3 - Derived data types */

   290

/********************************/

   291

   292

Issue 1

   293

=======

   294

   295

According to the spec, the valid construct

   296

TYPE new_str_type : STRING := "hello!"; END_TYPE

   297

has two possible routes to type_declaration...

   298

   299

Route 1:

   300

type_declaration: single_element_type_declaration

   301

single_element_type_declaration: simple_type_declaration

   302

simple_type_declaration: identifier ':' simple_spec_init

   303

simple_spec_init: simple_specification ASSIGN constant

   304

(shift:  identifier <- 'new_str_type')

   305

simple_specification: elementary_type_name

   306

elementary_type_name: STRING

   307

(shift: elementary_type_name <- STRING)

   308

(reduce: simple_specification <- elementary_type_name)

   309

(shift: constant <- "hello!")

   310

(reduce: simple_spec_init: simple_specification ASSIGN constant)

   311

(reduce: ...)

   312

   313

   314

Route 2:

   315

type_declaration: string_type_declaration

   316

string_type_declaration: identifier ':' elementary_string_type_name string_type_declaration_size string_type_declaration_init

   317

(shift:  identifier <- 'new_str_type')

   318

elementary_string_type_name: STRING

   319

(shift: elementary_string_type_name <- STRING)

   320

(shift: string_type_declaration_size <- /* empty */)

   321

string_type_declaration_init: ASSIGN character_string

   322

(shift: character_string <- "hello!")

   323

(reduce: string_type_declaration_init <- ASSIGN character_string)

   324

(reduce: string_type_declaration <- identifier ':' elementary_string_type_name string_type_declaration_size string_type_declaration_init )

   325

(reduce: type_declaration <- string_type_declaration)

   326

   327

   328

 At first glance it seems that removing route 1 would make

   329

the most sense. Unfortunately the construct 'simple_spec_init'

   330

shows up multiple times in other rules, so changing this construct

   331

would mean changing all the rules in which it appears.

   332

I (Mario) therefore chose to remove route 2 instead. This means

   333

that the above declaration gets stored in a

   334

simple_type_declaration_c, and not in a string_type_declaration_c

   335

as would be expected!

   336

   337

   338

/***********************/

   339

/* B 1.5.1 - Functions */

   340

/***********************/

   341

   342

   343

Issue 1

   344

=======

   345

   346

 Due to reduce/reduce conflicts between identifiers

   347

being reduced to either a variable or an enumerator value,

   348

we were forced to keep a symbol table of the names

   349

of all declared variables. Variables are no longer

   350

created from simple identifier_token, but from

   351

variable_name_token.

   352

   353

 BUT, in functions the function name may be used as

   354

a variable! In order to be able to parse this correctly,

   355

the token parser (flex) must return a variable_name_token

   356

when it comes across the function name, while parsing

   357

the function itself.

   358

We do this by inserting the function name into the variable

   359

symbol table, and having flex return a variable_name_token

   360

whenever it comes across it.

   361

When we finish parsing the function the variable name

   362

symbol table is cleared of all entries, and the function

   363

name is inserted into the library element symbol table. This

   364

means that from then onwards flex will return a

   365

derived_function_name_token whenever it comes across the

   366

function name.

   367

   368

In order to insert the function name into the variable_name

   369

symbol table BEFORE the function body gets parsed, we

   370

need the parser to reduce a construct that contains the

   371

the function name. That is why we created the extra

   372

construct 'function_name_declaration', i.e. to force

   373

the parser to reduce it, before parsing the function body,

   374

and therefore get an oportunity to insert the function name

   375

into the variable name symbol table!

   376

   377

   378

/********************************/

   379

/* B 3.2.4 Iteration Statements */

   380

/********************************/

   381

   382

Issue 1

   383

=======

   384

   385

For the 'FOR' iteration loop

   386

   387

  FOR control_variable ASSIGN expression TO expression BY expression DO statement_list END_FOR

   388

   389

The spec declares the control variable in the syntax as

   390

   391

  control_variable: identifier;

   392

   393

but then defines the semantics of control_variable (Section 3.3.2.4)

   394

as being of an integer type (e.g., SINT, INT, or DINT).

   395

Obviously this presuposes that the control_variable must have been

   396

declared in some 'VAR .. VAR_END' construct, so I (Mario) changed

   397

the syntax to read

   398

   399

  control_variable: variable_name;

   400

   401

   402

   403

   404

   405

**************************************************************************

   406

   407

  (c) 2003 Mario de Sousa