1

     2

     3

     4

  MATIEC - IEC 61131-3 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

  Copyright (C) 2003-2011  Mario de Sousa (msousa@fe.up.pt)

    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    - currently in its early stages

    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

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

    60

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

    61

programs directly into executable binaries, for all the processor

    62

architectures gcc currently supports.

    63

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

    64

data structure between these two stages is called the syntax

    65

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

    66

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

    67

Unfortunately the gcc syntax tree is not very well documented,

    68

and doing semantic checking on this tree would probably be a

    69

nightmare.

    70

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

    71

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

    72

do semantic checking on our tree, do whatever optimisation

    73

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

    74

the gcc syntax tree from our abstract syntax tree.

    75

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

    76

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

    77

Since generating the gcc syntax tree will probably envolve some

    78

trial and error effort due to the sparseness of documentation,

    79

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

    80

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

    81

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

    82

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

    83

    84

    85

    86

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

    87

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

    88

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

    89

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

    90

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

    91

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

    92

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

    93

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

    94

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

    95

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

    96

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

    97

    98

    99

   100

Issue 1

   101

=======

   102

   103

 The syntax defines the common_character_representation as:

   104

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

   105

   106

 Flex includes the function print_char() that defines

   107

all printable characters portably (i.e. whatever character

   108

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

   109

Unfortunately, we cannot generate the definition of

   110

common_character_representation portably, since flex

   111

does not allow definition of sets by subtracting

   112

elements in one set from another set (Note how

   113

common_character_representation could be defined by

   114

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

   115

This means we must build up the defintion of

   116

common_character_representation using only set addition,

   117

which leaves us with the only choice of defining the

   118

characters non-portably...

   119

   120

 In short, the definition we use for common_character_representation

   121

only works for ASCII character encoding!

   122

   123

   124

   125

   126

Issue 2

   127

=======

   128

   129

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

   130

other files. The accepted syntax is:

   131

   132

   {#include "<filename>" }

   133

   134

We use a pragma directive for this (allowed by the standard itself),

   135

 since it is an extension of the standard. In principle, this would 

   136

be ignored by other standard complient compilers!

   137

   138

   139

   140

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

   141

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

   142

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

   143

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

   144

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

   145

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

   146

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

   147

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

   148

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

   149

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

   150

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

   151

   152

 Overall Comments

   153

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

   154

   155

   156

 Comment 1

   157

 ---------

   158

 We have augmented the syntax the specification defines to include

   159

restrictions defined in the semantics of the languages.

   160

   161

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

   162

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

   163

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

   164

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

   165

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

   166

figure out if the identifier is a variable_name, enumeration

   167

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

   168

which it appears.

   169

   170

 A more detailed example of why we need symbol tables are

   171

the type definitions...  In definition of new types

   172

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

   173

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

   174

This works well when the base classes are elementary types

   175

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

   176

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

   177

user defined type.

   178

   179

TYPE

   180

  new_type_1 : INT := 99;

   181

  new_type_2 : new_type_1 := 100;

   182

END_TYPE

   183

   184

 When parsing new_type_1, the parser can figure out that the

   185

identifier new_type_1 is a simple_type_name, because it is

   186

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

   187

 While parsing new_type_2, it becomes confused how to reduce

   188

the new_type_2 identifier, as it is based on the identifier

   189

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

   190

stage new_type_1 is a simple identifier!).

   191

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

   192

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

   193

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

   194

cannot use the abstract syntax tree itself to search for the

   195

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

   196

of the tree at the end of the parsing.

   197

   198

 We therefore maintain an independent and parallel table of symbols,

   199

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

   200

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

   201

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

   202

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

   203

need to remove the variable names from the symbol table.

   204

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

   205

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

   206

the variable names that is completely cleared when the parser

   207

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

   208

   209

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

   210

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

   211

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

   212

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

   213

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

   214

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

   215

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

   216

when we reach the end. Checking whether variables declared

   217

as EXTERN really exist inside a RESOURCE or a CONFIGURATION

   218

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

   219

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

   220

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

   221

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

   222

   223

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

   224

tokens depending on the type of identifier it had previously

   225

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

   226

changed regarding the definition of variable names, derived

   227

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

   228

variable_name: identifier;

   229

TO

   230

variable_name: variable_name_token;

   231

   232

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

   233

and returns the correct token corresponding to the identifier

   234

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

   235

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

   236

   237

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

   238

were changed FROM:

   239

function_declaration: FUNCTION derived_function_name ...

   240

TO

   241

function_declaration: FUNCTION identifier ...

   242

since the initial definition of derived_function_name had been

   243

changed FROM

   244

derived_function_name: identifier;

   245

TO

   246

derived_function_name: derived_function_name_token;

   247

   248

   249

   250

   251

 Comment 2

   252

 ---------

   253

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

   254

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

   255

simultaneously. This approach has the advantage that the user

   256

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

   257

is written in a single lanuage.

   258

   259

 This approach also assumes that all the IL language operators are

   260

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

   261

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

   262

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

   263

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

   264

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

   265

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

   266

   267

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

   268

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

   269

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

   270

   271

   272

   273

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

   274

/* B 1.3.3 - Derived data types */

   275

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

   276

   277

Issue 1

   278

=======

   279

   280

According to the spec, the valid construct

   281

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

   282

has two possible routes to type_declaration...

   283

   284

Route 1:

   285

type_declaration: single_element_type_declaration

   286

single_element_type_declaration: simple_type_declaration

   287

simple_type_declaration: identifier ':' simple_spec_init

   288

simple_spec_init: simple_specification ASSIGN constant

   289

(shift:  identifier <- 'new_str_type')

   290

simple_specification: elementary_type_name

   291

elementary_type_name: STRING

   292

(shift: elementary_type_name <- STRING)

   293

(reduce: simple_specification <- elementary_type_name)

   294

(shift: constant <- "hello!")

   295

(reduce: simple_spec_init: simple_specification ASSIGN constant)

   296

(reduce: ...)

   297

   298

   299

Route 2:

   300

type_declaration: string_type_declaration

   301

string_type_declaration: identifier ':' elementary_string_type_name string_type_declaration_size string_type_declaration_init

   302

(shift:  identifier <- 'new_str_type')

   303

elementary_string_type_name: STRING

   304

(shift: elementary_string_type_name <- STRING)

   305

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

   306

string_type_declaration_init: ASSIGN character_string

   307

(shift: character_string <- "hello!")

   308

(reduce: string_type_declaration_init <- ASSIGN character_string)

   309

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

   310

(reduce: type_declaration <- string_type_declaration)

   311

   312

   313

 At first glance it seems that removing route 1 would make

   314

the most sense. Unfortunately the construct 'simple_spec_init'

   315

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

   316

would mean changing all the rules in which it appears.

   317

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

   318

that the above declaration gets stored in a

   319

simple_type_declaration_c, and not in a string_type_declaration_c

   320

as would be expected!

   321

   322

   323

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

   324

/* B 1.5.1 - Functions */

   325

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

   326

   327

   328

Issue 1

   329

=======

   330

   331

 Due to reduce/reduce conflicts between identifiers

   332

being reduced to either a variable or an enumerator value,

   333

we were forced to keep a symbol table of the names

   334

of all declared variables. Variables are no longer

   335

created from simple identifier_token, but from

   336

variable_name_token.

   337

   338

 BUT, in functions the function name may be used as

   339

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

   340

the token parser (flex) must return a variable_name_token

   341

when it comes across the function name, while parsing

   342

the function itself.

   343

We do this by inserting the function name into the variable

   344

symbol table, and having flex return a variable_name_token

   345

whenever it comes across it.

   346

When we finish parsing the function the variable name

   347

symbol table is cleared of all entries, and the function

   348

name is inserted into the library element symbol table. This

   349

means that from then onwards flex will return a

   350

derived_function_name_token whenever it comes across the

   351

function name.

   352

   353

In order to insert the function name into the variable_name

   354

symbol table BEFORE the function body gets parsed, we

   355

need the parser to reduce a construct that contains the

   356

the function name. That is why we created the extra

   357

construct 'function_name_declaration', i.e. to force

   358

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

   359

and therefore get an oportunity to insert the function name

   360

into the variable name symbol table!

   361

   362

   363

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

   364

/* B 3.2.4 Iteration Statements */

   365

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

   366

   367

Issue 1

   368

=======

   369

   370

For the 'FOR' iteration loop

   371

   372

  FOR control_variable ASSIGN expression TO expression BY expression DO statement_list END_FOR

   373

   374

The spec declares the control variable in the syntax as

   375

   376

  control_variable: identifier;

   377

   378

but then defines the semantics of control_variable (Section 3.3.2.4)

   379

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

   380

Obviously this presuposes that the control_variable must have been

   381

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

   382

the syntax to read

   383

   384

  control_variable: variable_name;

   385

   386

   387

   388

   389

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

   390

   391

  Copyright (C) 2003-2011  Mario de Sousa (msousa@fe.up.pt)