1

/*

     2

 *  matiec - a compiler for the programming languages defined in IEC 61131-3

     3

 *

     4

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

     5

 *

     6

 *  This program is free software: you can redistribute it and/or modify

     7

 *  it under the terms of the GNU General Public License as published by

     8

 *  the Free Software Foundation, either version 3 of the License, or

     9

 *  (at your option) any later version.

    10

 *

    11

 *  This program is distributed in the hope that it will be useful,

    12

 *  but WITHOUT ANY WARRANTY; without even the implied warranty of

    13

 *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the

    14

 *  GNU General Public License for more details.

    15

 *

    16

 *  You should have received a copy of the GNU General Public License

    17

 *  along with this program.  If not, see <http://www.gnu.org/licenses/>.

    18

 *

    19

 *

    20

 * This code is made available on the understanding that it will not be

    21

 * used in safety-critical situations without a full and competent review.

    22

 */

    23

    24

/*

    25

 * An IEC 61131-3 compiler.

    26

 *

    27

 * Based on the

    28

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

    29

 *

    30

 */

    31

    32

/*

    33

 * Stage 1

    34

 * =======

    35

 *

    36

 * This file contains the lexical tokens definitions, from which

    37

 * the flex utility will generate a lexical parser function.

    38

 */

    39

    40

    41

    42

    43

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

    44

/* Lexical Parser Options... */

    45

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

    46

    47

/* The lexical analyser will never work in interactive mode,

    48

 * i.e., it will only process programs saved to files, and never

    49

 * programs being written inter-actively by the user.

    50

 * This option saves the resulting parser from calling the

    51

 * isatty() function, that seems to be generating some compile

    52

 * errors under some (older?) versions of flex.

    53

 */

    54

%option never-interactive

    55

    56

/* Have the lexical analyser use a 'char *yytext' instead of an

    57

 * array of char 'char yytext[??]' to store the lexical token.

    58

 */

    59

%pointer

    60

    61

    62

/* Have the lexical analyser ignore the case of letters.

    63

 * This will occur for all the tokens and keywords, but

    64

 * the resulting text handed up to the syntax parser

    65

 * will not be changed, and keep the original case

    66

 * of the letters in the input file.

    67

 */

    68

%option case-insensitive

    69

    70

/* Have the generated lexical analyser keep track of the

    71

 * line number it is currently analysing.

    72

 * This is used to pass up to the syntax parser

    73

 * the number of the line on which the current

    74

 * token was found. It will enable the syntax parser

    75

 * to generate more informatve error messages...

    76

 */

    77

%option yylineno

    78

    79

/* required for the use of the yy_pop_state() and

    80

 * yy_push_state() functions

    81

 */

    82

%option stack

    83

    84

/* The '%option stack' also requests the inclusion of 

    85

 * the yy_top_state(), however this function is not

    86

 * currently being used. This means that the compiler

    87

 * is complaining about the existance of this function.

    88

 * The following option removes the yy_top_state()

    89

 * function from the resulting c code, so the compiler 

    90

 * no longer complains.

    91

 */

    92

%option noyy_top_state

    93

    94

/* We will not be using unput() in our flex code... */

    95

%option nounput

    96

    97

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

    98

/* External Variable and Function declarations... */

    99

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

   100

   101

   102

%{

   103

/* Define TEST_MAIN to include a main() function.

   104

 * Useful for testing the parser generated by flex.

   105

 */

   106

/*

   107

#define TEST_MAIN

   108

*/

   109

/* If lexical parser is compiled by itself, we need to define the following

   110

 * constant to some string. Under normal circumstances LIBDIRECTORY is set

   111

 * in the syntax parser header file...

   112

 */

   113

#ifdef TEST_MAIN

   114

#define DEFAULT_LIBDIR "just_testing"

   115

#endif

   116

   117

   118

   119

/* Required for strdup() */

   120

#include <string.h>

   121

   122

/* Required only for the declaration of abstract syntax classes

   123

 * (class symbol_c; class token_c; class list_c;)

   124

 * These will not be used in flex, but the token type union defined

   125

 * in iec.hh contains pointers to these classes, so we must include

   126

 * it here.

   127

 */

   128

#include "../absyntax/absyntax.hh"

   129

   130

   131

/* generated by bison.

   132

 * Contains the definition of the token constants, and the

   133

 * token value type YYSTYPE (in our case, a 'const char *')

   134

 */

   135

#include "iec.y.hh"

   136

#include "stage1_2_priv.hh"

   137

   138

   139

/* Variable defined by the bison parser,

   140

 * where the value of the tokens will be stored

   141

 */

   142

extern YYSTYPE yylval;

   143

   144

/* The name of the file currently being parsed...

   145

 * This variable is declared and read from the code generated by bison!

   146

 * Note that flex accesses and updates this global variable

   147

 * apropriately whenever it comes across an (*#include <filename> *)

   148

 * directive...

   149

 */

   150

/*

   151

 NOTE: already defined in iec.y.hh 

   152

extern const char *current_filename;

   153

*/

   154

   155

   156

/* We will not be using unput() in our flex code... */

   157

/* NOTE: it seems that this #define is no longer needed, It has been 

   158

 * replaced by %option nounput.

   159

 * Should we simply delete it?

   160

 * For now leave it in, in case someone is using an old version of flex.

   161

 * In any case, the most harm that can result in a warning message

   162

 * when compiling iec.flex.c:

   163

 * warning: ‘void yyunput(int, char*)’ defined but not used

   164

 */

   165

#define YY_NO_UNPUT

   166

   167

/* Variable defined by the bison parser.

   168

 * It must be initialised with the location

   169

 * of the token being parsed.

   170

 * This is only needed if we want to keep

   171

 * track of the locations, in order to give

   172

 * more meaningful error messages!

   173

 */

   174

extern YYLTYPE yylloc;

   175

   176

#define YY_INPUT(buf,result,max_size)  {\

   177

    result = GetNextChar(buf, max_size);\

   178

    if (  result <= 0  )\

   179

      result = YY_NULL;\

   180

    }

   181

   182

/* Macro that is executed for every action.

   183

 * We use it to pass the location of the token

   184

 * back to the bison parser...

   185

 */

   186

#define YY_USER_ACTION {\

   187

	  yylloc.first_line = current_tracking->lineNumber;\

   188

  	yylloc.first_column = current_tracking->currentTokenStart;\

   189

  	yylloc.last_line = current_tracking->lineNumber;\

   190

  	yylloc.last_column = current_tracking->currentChar - 1;\

   191

  	current_tracking->currentTokenStart = current_tracking->currentChar;\

   192

	}

   193

   194

   195

/* Since this lexical parser we defined only works in ASCII based

   196

 * systems, we might as well make sure it is being compiled on

   197

 * one...

   198

 * Lets check a few random characters...

   199

 */

   200

#if (('a' != 0x61) || ('A' != 0x41) || ('z' != 0x7A) || ('Z' != 0x5A) || \

   201

     ('0' != 0x30) || ('9' != 0x39) || ('(' != 0x28) || ('[' != 0x5B))

   202

#error This lexical analyser is not portable to a non ASCII based system.

   203

#endif

   204

   205

   206

/* Function only called from within flex, but defined

   207

 * in iec.y!

   208

 * We declare it here...

   209

 *

   210

 * Search for a symbol in either of the two symbol tables

   211

 * and return the token id of the first symbol found.

   212

 * Searches first in the variables, and only if not found

   213

 * does it continue searching in the library elements

   214

 */

   215

//token_id_t get_identifier_token(const char *identifier_str);

   216

int get_identifier_token(const char *identifier_str);

   217

%}

   218

   219

   220

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

   221

/* Forward Declaration of functions defined later. */

   222

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

   223

   224

%{

   225

/* return all the text in the current token back to the input stream. */

   226

void unput_text(unsigned int n);

   227

%}

   228

   229

   230

   231

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

   232

/* Lexical Parser States... */

   233

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

   234

   235

/* NOTE: Our psrser can parse st or il code, intermixed

   236

 *       within the same file.

   237

 *       With IL we come across the issue of the EOL (end of line) token.

   238

 *       ST, and the declaration parts of IL do not use this token!

   239

 *       If the lexical analyser were to issue this token during ST

   240

 *       language parsing, or during the declaration of data types,

   241

 *       function headers, etc. in IL, the syntax parser would crash.

   242

 *

   243

 *       We can solve this issue using one of three methods:

   244

 *        (1) Augment all the syntax that does not accept the EOL

   245

 *            token to simply ignore it. This makes the syntax

   246

 *            definition (in iec.y) very cluttered!

   247

 *        (2) Let the lexical parser figure out which language

   248

 *            it is parsing, and decide whether or not to issue

   249

 *            the EOL token. This requires the lexical parser

   250

 *            to have knowledge of the syntax!, making for a poor

   251

 *            overall organisation of the code. It would also make it

   252

 *            very difficult to understand the lexical parser as it

   253

 *            would use several states, and a state machine to transition

   254

 *            between the states. The state transitions would be

   255

 *            intermingled with the lexical parser defintion!

   256

 *        (3) Use a mixture of (1) and (2). The lexical analyser

   257

 *            merely distinguishes between function headers and function

   258

 *            bodies, but no longer makes a distinction between il and

   259

 *            st language bodies. When parsing a body, it will return

   260

 *            the EOL token. In other states '\n' will be ignored as

   261

 *            whitespace.

   262

 *            The ST language syntax has been augmented in the syntax

   263

 *            parser configuration to ignore any EOL tokens that it may

   264

 *            come across!

   265

 *            This option has both drawbacks of option (1) and (2), but

   266

 *            much less intensely.

   267

 *            The syntax that gets cluttered is limited to the ST statements

   268

 *            (which is rather limited, compared to the function headers and

   269

 *            data type declarations, etc...), while the state machine in

   270

 *            the lexical parser becomes very simple. All state transitions

   271

 *            can be handled within the lexical parser by itself, and can be

   272

 *            easily identified. Thus knowledge of the syntax required by

   273

 *            the lexical parser is very limited!

   274

 *

   275

 * Amazingly enough, I (Mario) got to implement option (3)

   276

 * at first, requiring two basic states, decl and body.

   277

 * The lexical parser will enter the body state when

   278

 * it is parsing the body of a function/program/function block. The

   279

 * state transition is done when we find a VAR_END that is not followed

   280

 * by a VAR! This is the syntax knowledge that gets included in the

   281

 * lexical analyser with this option!

   282

 * Unfortunately, getting the st syntax parser to ignore EOL anywhere

   283

 * where they might appear leads to conflicts. This is due to the fact

   284

 * that the syntax parser uses the single look-ahead token to remove

   285

 * possible conflicts. When we insert a possible EOL, the single

   286

 * look ahead token becomes the EOL, which means the potential conflicts

   287

 * could no longer be resolved.

   288

 * Removing these conflicts would make the st syntax parser very convoluted,

   289

 * and adding the extraneous EOL would make it very cluttered.

   290

 * This option was therefore dropped in favour of another!

   291

 *

   292

 * I ended up implementing (2). Unfortunately the lexical analyser can

   293

 * not easily distinguish between il and st code, since function

   294

 * calls in il are very similar to function block calls in st.

   295

 * We therefore use an extra 'body' state. When the lexical parser

   296

 * finds that last END_VAR, it enters the body state. This state

   297

 * must figure out what language is being parsed from the first few

   298

 * tokens, and switch to the correct state (st, il or sfc) according to the

   299

 * language. This means that we insert quite a bit of knowledge of the

   300

 * syntax of the languages into the lexical parser. This is ugly, but it

   301

 * works, and at least it is possible to keep all the state changes together

   302

 * to make it easier to remove them later on if need be.

   303

 * Once the language being parsed has been identified, 

   304

 * the body state returns any matched text back to the buffer with unput(),

   305

 * to be later matched correctly by the apropriate language parser (st, il or sfc).

   306

 *

   307

 * Aditionally, in sfc state it may further recursively enter the body state

   308

 * once again. This is because an sfc body may contain ACTIONS, which are then

   309

 * written in one of the three languages (ST, IL or SFC), so once again we need

   310

 * to figure out which language the ACTION in the SFC was written in. We already

   311

 * ahve all that done in the body state, so we recursively transition to the body 

   312

 * state once again.

   313

 * Note that in this case, when coming out of the st/il state (whichever language

   314

 * the action was written in) the sfc state will become active again. This is done by

   315

 * pushing and poping the previously active state!

   316

 *

   317

 * The sfc_qualifier_state is required because when parsing actions within an

   318

 * sfc, we will be expecting action qualifiers (N, P, R, S, DS, SD, ...). In order

   319

 * to bison to work correctly, these qualifiers must be returned as tokens. However,

   320

 * these tokens are not reserved keywords, which means it should be possible to

   321

 * define variables/functions/FBs with any of these names (including 

   322

 * S and R which are special because they are also IL operators). So, when we are not

   323

 * expecting any action qualifiers, flex does not return these tokens, and is free

   324

 * to interpret them as previously defined variables/functions/... as the case may be.

   325

 *

   326

 * The state machine has 7 possible states (INITIAL, config, decl, body, st, il, sfc)

   327

 * Possible state changes are:

   328

 *   INITIAL -> goto(decl_state)

   329

 *               (when a FUNCTION, FUNCTION_BLOCK, or PROGRAM is found,

   330

 *                and followed by a VAR declaration)

   331

 *   INITIAL -> goto(body_state) 

   332

 *                (when a FUNCTION, FUNCTION_BLOCK, or PROGRAM is found,

   333

 *                 and _not_ followed by a VAR declaration)

   334

 *                (This transition is actually commented out, since the syntax

   335

 *                 does not allow the declaration of functions, FBs, or programs

   336

 *                 without any VAR declaration!)

   337

 *   INITIAL -> goto(config_state)

   338

 *                (when a CONFIGURATION is found)

   339

 *   decl_state    -> push(decl_state); goto(body_state)

   340

 *                     (when the last END_VAR is found, i.e. the function body starts)

   341

 *   decl_state    -> push(decl_state); goto(sfc_state)

   342

 *                     (when it figures out it is parsing sfc language)

   343

 *   body_state    -> goto(st_state)

   344

 *                     (when it figures out it is parsing st language)

   345

 *   body_state    -> goto(il_state)

   346

 *                     (when it figures out it is parsing il language)

   347

 *   st_state      -> pop()

   348

 *                     (when a END_FUNCTION, END_FUNCTION_BLOCK, END_PROGRAM,

   349

 *                      END_ACTION or END_TRANSITION is found)

   350

 *   il_state      -> pop()

   351

 *                     (when a END_FUNCTION, END_FUNCTION_BLOCK, END_PROGRAM,

   352

 *                      END_ACTION or END_TRANSITION is found)

   353

 *   decl_state    -> goto(INITIAL)

   354

 *                     (when a END_FUNCTION, END_FUNCTION_BLOCK, or END_PROGRAM is found)

   355

 *   sfc_state     -> goto(INITIAL)

   356

 *                     (when a END_FUNCTION, END_FUNCTION_BLOCK, or END_PROGRAM is found)

   357

 *   config_state  -> goto(INITIAL)

   358

 *                     (when a END_CONFIGURATION is found)

   359

 *   sfc_state     -> push(sfc_state); goto(body_state)

   360

 *                     (when parsing an action. This transition is requested by bison)

   361

 *   sfc_state     -> push(sfc_state); goto(sfc_qualifier_state)

   362

 *                     (when expecting an action qualifier. This transition is requested by bison)

   363

 *   sfc_qualifier_state -> pop()

   364

 *                     (when no longer expecting an action qualifier. This transition is requested by bison)

   365

 *   config_state  -> push(config_state); goto(task_init_state)

   366

 *                     (when parsing a task initialisation. This transition is requested by bison)

   367

 *   task_init_state -> pop()

   368

 *                     (when no longer parsing task initialisation parameters. This transition is requested by bison)

   369

 *

   370

 */

   371

   372

   373

/* we are parsing a configuration. */

   374

%s config_state

   375

   376

/* Inside a configuration, we are parsing a task initialisation parameters */

   377

/* This means that PRIORITY, SINGLE and INTERVAL must be handled as

   378

 * tokens, and not as possible identifiers. Note that the above words

   379

 * are not keywords.

   380

 */

   381

%s task_init_state

   382

   383

/* we are parsing a function, program or function block declaration */

   384

%s decl_state

   385

   386

/* we will be parsing a function body. Whether il/st is remains unknown */

   387

%x body_state

   388

   389

/* we are parsing il code -> flex must return the EOL tokens!       */

   390

%s il_state

   391

   392

/* we are parsing st code -> flex must not return the EOL tokens!   */

   393

%s st_state

   394

   395

/* we are parsing sfc code -> flex must not return the EOL tokens!  */

   396

%s sfc_state

   397

   398

/* we are parsing sfc code, and expecting an action qualifier.      */

   399

%s sfc_qualifier_state

   400

   401

/* we are parsing sfc code, and expecting the priority token.       */

   402

%s sfc_priority_state

   403

   404

   405

   406

   407

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

   408

/* File #include's */

   409

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

   410

   411

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

   412

 * of other files, using the IEC 61131-3 pragma directive...

   413

 * The accepted syntax is:

   414

 *  {#include "<filename>"}

   415

 */

   416

   417

/* the "include" states are used for picking up the name of an include file */

   418

%x include_beg

   419

%x include_filename

   420

%x include_end

   421

   422

   423

file_include_pragma_filename	[^\"]*

   424

file_include_pragma_beg		"{#include"{st_whitespace_only}\"

   425

file_include_pragma_end		\"{st_whitespace_only}"}"

   426

file_include_pragma			{file_include_pragma_beg}{file_include_pragma_filename}{file_include_pragma_end}

   427

   428

   429

%{

   430

#define MAX_INCLUDE_DEPTH 16

   431

   432

typedef struct {

   433

	  YY_BUFFER_STATE buffer_state;

   434

	  tracking_t* env;

   435

	  const char *filename;

   436

	} include_stack_t;

   437

   438

tracking_t* current_tracking;

   439

include_stack_t include_stack[MAX_INCLUDE_DEPTH];

   440

int include_stack_ptr = 0;

   441

   442

const char *INCLUDE_DIRECTORIES[] = {

   443

	DEFAULT_LIBDIR,

   444

	".",

   445

	"/lib",

   446

	"/usr/lib",

   447

	"/usr/lib/iec",

   448

	NULL /* must end with NULL!! */

   449

	};

   450

   451

%}

   452

   453

   454

   455

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

   456

/* Prelimenary constructs... */

   457

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

   458

   459

/* In order to allow the declaration of POU prototypes (Function, FB, Program, ...),

   460

 * especially the prototypes of Functions and FBs defined in the standard

   461

 * (i.e. standard functions and FBs), we extend the IEC 61131-3 standard syntax 

   462

 * with two pragmas to indicate that the code is to be parsed (going through the 

   463

 * lexical, syntactical, and semantic analysers), but no code is to be generated.

   464

 * 

   465

 * The accepted syntax is:

   466

 *  {no_code_generation begin}

   467

 *    ... prototypes ...

   468

 *  {no_code_generation end}

   469

 * 

   470

 * When parsing these prototypes the abstract syntax tree will be populated as usual,

   471

 * allowing the semantic analyser to correctly analyse the semantics of calls to these

   472

 * functions/FBs. However, stage4 will simply ignore all IEC61131-3 code

   473

 * between the above two pragmas.

   474

 */

   475

   476

disable_code_generation_pragma	"{disable code generation}"

   477

enable_code_generation_pragma	"{enable code generation}"

   478

   479

   480

/* Any other pragma... */

   481

   482

pragma "{"[^}]*"}"

   483

   484

/* NOTE: this seemingly unnecessary complex definition is required

   485

 *       to be able to eat up comments such as:

   486

 *          '(* Testing... ! ***** ******)'

   487

 *       without using the trailing context command in flex (/{context})

   488

 *       since {comment} itself will later be used with

   489

 *       trailing context ({comment}/{context})

   490

 */

   491

not_asterisk				[^*]

   492

not_close_parenthesis_nor_asterisk	[^*)]

   493

asterisk				"*"

   494

comment_text		{not_asterisk}|(({asterisk}+){not_close_parenthesis_nor_asterisk})

   495

   496

comment		"(*"({comment_text}*)({asterisk}+)")"

   497

   498

   499

/*

   500

3.1 Whitespace

   501

 (NOTE: Whitespace IS clearly defined, to include newline!!! See section 2.1.4!!!)

   502

 No definition of whitespace is given, in other words, the characters that may be used to seperate language tokens are not pecisely defined. One may nevertheless make an inteligent guess of using the space (' '), and other characters also commonly considered whitespace in other programming languages (horizontal tab, vertical tab, form feed, etc.).

   503

 The main question is whether the newline character should be considered whitespace. IL language statements use an EOL token (End Of Line) to distinguish between some language constructs. The EOL token itself is openly defined as "normally consist[ing] of the 'paragraph separator' ", leaving the final choice open to each implemention. If we choose the newline character to represent the EOL token, it may then not be considered whitespace.

   504

 On the other hand, some examples that come in a non-normative annex of the specification allow function declarations to span multiple3.1 Whitespace

   505

 (NOTE: Whitespace IS clearly defined, to include newline!!! See section 2.1.4!!!)

   506

 No definition of whitespace is given, in other words, the characters that may be used to seperate language tokens are not pecisely defined. One may nevertheless make an inteligent guess of using the space (' '), and other characters also commonly considered whitespace in other programming languages (horizontal tab, vertical tab, form feed, etc.).

   507

 The main question is whether the newline character should be considered whitespace. IL language statements use an EOL token (End Of Line) to distinguish between some language constructs. The EOL token itself is openly defined as "normally consist[ing] of the 'paragraph separator' ", leaving the final choice open to each implemention. If we choose the newline character to represent the EOL token, it may then not be considered whitespace.

   508

 On the other hand, some examples that come in a non-normative annex of the specification allow function declarations to span multiple lines, which means that the newline character is being considered as whitespace.

   509

 Our implementation works around this issue by including the new line character in the whitespace while parsing function declarations and the ST language, and parsing it as the EOL token only while parsing IL language statements. This requires the use of a state machine in the lexical parser that needs at least some knowledge of the syntax itself.

   510

*/

   511

/* NOTE: Our definition of whitespace will only work in ASCII!

   512

 *

   513

 *       Since the IL language needs to know the location of newline

   514

 *       (token EOL -> '\n' ), we need one definition of whitespace