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_bison.h contains pointers to these classes, so we must include

   126

 * it here.

   127

 */

   128

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

   129

   130

   131

/* iec_bison.h is 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_bison.h"

   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_bison.h 

   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

   183

/* A counter to track the order by which each token is processed.

   184

 * NOTE: This counter is not exactly linear (i.e., it does not get incremented by 1 for each token).

   185

 *       i.e.. it may get incremented by more than one between two consecutive tokens.

   186

 *       This is due to the fact that the counter gets incremented every 'user action' in flex,

   187

 *       however not every user action will result in a token being passed to bison.

   188

 *       Nevertheless this is still OK, as we are only interested in the relative

   189

 *       ordering of tokens...

   190

 */

   191

static long int current_order = 0;

   192

   193

   194

/* Macro that is executed for every action.

   195

 * We use it to pass the location of the token

   196

 * back to the bison parser...

   197

 */

   198

#define YY_USER_ACTION {\

   199

	yylloc.first_line = current_tracking->lineNumber;			\

   200

	yylloc.first_column = current_tracking->currentTokenStart;		\

   201

	yylloc.first_file = current_filename;					\

   202

	yylloc.first_order = current_order;					\

   203

	yylloc.last_line = current_tracking->lineNumber;			\

   204

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

   205

	yylloc.last_file = current_filename;					\

   206

	yylloc.last_order = current_order;					\

   207

	current_tracking->currentTokenStart = current_tracking->currentChar;	\

   208

	current_order++;							\

   209

	}

   210

   211

   212

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

   213

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

   214

 * one...

   215

 * Lets check a few random characters...

   216

 */

   217

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

   218

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

   219

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

   220

#endif

   221

   222

   223

/* Function only called from within flex, but defined

   224

 * in iec.y!

   225

 * We declare it here...

   226

 *

   227

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

   228

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

   229

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

   230

 * does it continue searching in the library elements

   231

 */

   232

//token_id_t get_identifier_token(const char *identifier_str);

   233

int get_identifier_token(const char *identifier_str);

   234

%}

   235

   236

   237

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

   238

/* Forward Declaration of functions defined later. */

   239

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

   240

   241

%{

   242

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

   243

void unput_text(unsigned int n);

   244

%}

   245

   246

   247

   248

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

   249

/* Lexical Parser States... */

   250

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

   251

   252

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

   253

 *       within the same file.

   254

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

   255

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

   256

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

   257

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

   258

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

   259

 *

   260

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

   261

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

   262

 *            token to simply ignore it. This makes the syntax

   263

 *            definition (in iec.y) very cluttered!

   264

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

   265

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

   266

 *            the EOL token. This requires the lexical parser

   267

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

   268

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

   269

 *            very difficult to understand the lexical parser as it

   270

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

   271

 *            between the states. The state transitions would be

   272

 *            intermingled with the lexical parser defintion!

   273

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

   274

 *            merely distinguishes between function headers and function

   275

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

   276

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

   277

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

   278

 *            whitespace.

   279

 *            The ST language syntax has been augmented in the syntax

   280

 *            parser configuration to ignore any EOL tokens that it may

   281

 *            come across!

   282

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

   283

 *            much less intensely.

   284

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

   285

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

   286

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

   287

 *            the lexical parser becomes very simple. All state transitions

   288

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

   289

 *            easily identified. Thus knowledge of the syntax required by

   290

 *            the lexical parser is very limited!

   291

 *

   292

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

   293

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

   294

 * The lexical parser will enter the body state when

   295

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

   296

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

   297

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

   298

 * lexical analyser with this option!

   299

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

   300

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

   301

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

   302

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

   303

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

   304

 * could no longer be resolved.

   305

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

   306

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

   307

 * This option was therefore dropped in favour of another!

   308

 *

   309

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

   310

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

   311

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

   312

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

   313

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

   314

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

   315

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

   316

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

   317

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

   318

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

   319

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

   320

 * Once the language being parsed has been identified, 

   321

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

   322

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

   323

 *

   324

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

   325

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

   326

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

   327

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

   328

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

   329

 * state once again.

   330

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

   331

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

   332

 * pushing and poping the previously active state!

   333

 *

   334

 * The sfc_qualifier_state is required because when parsing actions within an

   335

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

   336

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

   337

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

   338

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

   339

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

   340

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

   341

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

   342

 *

   343

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

   344

 * Possible state changes are:

   345

 *   INITIAL -> goto(decl_state)

   346

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

   347

 *                and followed by a VAR declaration)

   348

 *   INITIAL -> goto(body_state) 

   349

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

   350

 *                 and _not_ followed by a VAR declaration)

   351

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

   352

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

   353

 *                 without any VAR declaration!)

   354

 *   INITIAL -> goto(config_state)

   355

 *                (when a CONFIGURATION is found)

   356

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

   357

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

   358

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

   359

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

   360

 *   body_state    -> goto(st_state)

   361

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

   362

 *   body_state    -> goto(il_state)

   363

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

   364

 *   st_state      -> pop()

   365

 *                     (when a END_FUNCTION, END_FUNCTION_BLOCK, END_PROGRAM,

   366

 *                      END_ACTION or END_TRANSITION is found)

   367

 *   il_state      -> pop()

   368

 *                     (when a END_FUNCTION, END_FUNCTION_BLOCK, END_PROGRAM,

   369

 *                      END_ACTION or END_TRANSITION is found)

   370

 *   decl_state    -> goto(INITIAL)

   371

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

   372

 *   sfc_state     -> goto(INITIAL)

   373

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

   374

 *   config_state  -> goto(INITIAL)

   375

 *                     (when a END_CONFIGURATION is found)

   376

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

   377

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

   378

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

   379

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

   380

 *   sfc_qualifier_state -> pop()

   381

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

   382

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

   383

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

   384

 *   task_init_state -> pop()

   385

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

   386

 *

   387

 */

   388

   389

   390

/* we are parsing a configuration. */

   391

%s config_state

   392

   393

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

   394

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

   395

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

   396

 * are not keywords.

   397

 */

   398

%s task_init_state

   399

   400

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

   401

%s decl_state

   402

   403

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

   404

%x body_state

   405

   406

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

   407

%s il_state

   408

   409

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

   410

%s st_state

   411

   412

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

   413

%s sfc_state

   414

   415

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

   416

%s sfc_qualifier_state

   417

   418

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

   419

%s sfc_priority_state

   420

   421

   422

   423

   424

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

   425

/* File #include's */

   426

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

   427

   428

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

   429

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

   430

 * The accepted syntax is:

   431

 *  {#include "<filename>"}

   432

 */

   433

   434

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

   435

%x include_beg

   436

%x include_filename

   437

%x include_end

   438

   439

   440

file_include_pragma_filename	[^\"]*

   441

file_include_pragma_beg		"{#include"{st_whitespace_only}\"

   442

file_include_pragma_end		\"{st_whitespace_only}"}"

   443

file_include_pragma			{file_include_pragma_beg}{file_include_pragma_filename}{file_include_pragma_end}

   444

   445

   446

%{

   447

#define MAX_INCLUDE_DEPTH 16

   448

   449

typedef struct {

   450

	  YY_BUFFER_STATE buffer_state;

   451

	  tracking_t* env;

   452

	  const char *filename;

   453

	} include_stack_t;

   454

   455

tracking_t* current_tracking;

   456

include_stack_t include_stack[MAX_INCLUDE_DEPTH];

   457

int include_stack_ptr = 0;

   458

   459

const char *INCLUDE_DIRECTORIES[] = {

   460

	DEFAULT_LIBDIR,

   461

	".",

   462

	"/lib",

   463

	"/usr/lib",

   464

	"/usr/lib/iec",

   465

	NULL /* must end with NULL!! */

   466

	};

   467

   468

%}

   469

   470

   471

   472

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

   473

/* Prelimenary constructs... */

   474

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

   475

   476

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

   477

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

   478

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

   479

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

   480

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

   481

 * 

   482

 * The accepted syntax is:

   483

 *  {no_code_generation begin}

   484

 *    ... prototypes ...

   485

 *  {no_code_generation end}

   486

 * 

   487

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

   488

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

   489

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

   490

 * between the above two pragmas.

   491

 */

   492

   493

disable_code_generation_pragma	"{disable code generation}"

   494

enable_code_generation_pragma	"{enable code generation}"

   495

   496

   497

/* Any other pragma... */

   498

   499

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

   500

   501

/* NOTE: this seemingly unnecessary complex definition is required

   502

 *       to be able to eat up comments such as:

   503

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

   504

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

   505

 *       since {comment} itself will later be used with

   506

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

   507

 */

   508

not_asterisk				[^*]

   509

not_close_parenthesis_nor_asterisk	[^*)]

   510

asterisk				"*"

   511

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

   512