stage1_2/iec.flex
author lbessard
Thu, 02 Aug 2007 16:56:56 +0200
changeset 49 c96d1a4c23f8
parent 40 873a5b60a7ea
child 58 273d6d5cec9d
permissions -rwxr-xr-x
Changing file headers
Modifying SFC generation
/*
 * (c) 2003 Mario de Sousa
 *
 * Offered to the public under the terms of the GNU General Public License
 * as published by the Free Software Foundation; either version 2 of the
 * License, or (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful, but
 * WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General
 * Public License for more details.
 *
 * This code is made available on the understanding that it will not be
 * used in safety-critical situations without a full and competent review.
 */

/*
 * An IEC 61131-3 IL and ST compiler.
 *
 * Based on the
 * FINAL DRAFT - IEC 61131-3, 2nd Ed. (2001-12-10)
 *
 */

/*
 * Stage 1
 * =======
 *
 * This file contains the lexical tokens definitions, from which
 * the flex utility will generate a lexical parser function.
 */




/*****************************/
/* Lexical Parser Options... */
/*****************************/

/* The lexical analyser will never work in interactive mode,
 * i.e., it will only process programs saved to files, and never
 * programs being written inter-actively by the user.
 * This option saves the resulting parser from calling the
 * isatty() function, that seems to be generating some compile
 * errors under some (older?) versions of flex.
 */
%option never-interactive

/* Have the lexical analyser use a 'char *yytext' instead of an
 * array of char 'char yytext[??]' to store the lexical token.
 */
%pointer


/* Have the lexical analyser ignore the case of letters.
 * This will occur for all the tokens and keywords, but
 * the resulting text handed up to the syntax parser
 * will not be changed, and keep the original case
 * of the letters in the input file.
 */
%option case-insensitive

/* Have the generated lexical analyser keep track of the
 * line number it is currently analysing.
 * This is used to pass up to the syntax parser
 * the number of the line on which the current
 * token was found. It will enable the syntax parser
 * to generate more informatve error messages...
 */
%option yylineno

/* required for the use of the yy_pop_state() and
 * yy_push_state() functions
 */
%option stack

/* The '%option stack' also requests the inclusion of 
 * the yy_top_state(), however this function is not
 * currently being used. This means that the compiler
 * is complaining about the existance of this function.
 * The following option removes the yy_top_state()
 * function from the resulting c code, so the compiler 
 * no longer complains.
 */
%option noyy_top_state

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


%{
/* Define TEST_MAIN to include a main() function.
 * Useful for testing the parser generated by flex.
 */
/*
#define TEST_MAIN
*/
/* If lexical parser is compiled by itself, we need to define the following
 * constant to some string. Under normal circumstances LIBDIRECTORY is set
 * in the syntax parser header file...
 */
#ifdef TEST_MAIN
#define DEFAULT_LIBDIR "just_testing"
#endif



/* Required for strdup() */
#include <string.h>

/* Required only for the declaration of abstract syntax classes
 * (class symbol_c; class token_c; class list_c;)
 * These will not be used in flex, but the token type union defined
 * in iec.hh contains pointers to these classes, so we must include
 * it here.
 */
#include "../absyntax/absyntax.hh"


/* generated by bison.
 * Contains the definition of the token constants, and the
 * token value type YYSTYPE (in our case, a 'const char *')
 */
#include "iec.y.hh"
#include "stage1_2_priv.hh"


/* Variable defined by the bison parser,
 * where the value of the tokens will be stored
 */
extern YYSTYPE yylval;

/* The name of the file currently being parsed...
 * This variable is declared and read from the code generated by bison!
 * Note that flex accesses and updates this global variable
 * apropriately whenever it comes across an (*#include <filename> *)
 * directive...
 */
/*
 NOTE: already defined in iec.y.hh 
extern const char *current_filename;
*/


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

/* Variable defined by the bison parser.
 * It must be initialised with the location
 * of the token being parsed.
 * This is only needed if we want to keep
 * track of the locations, in order to give
 * more meaningful error messages!
 */
extern YYLTYPE yylloc;

/* Macro that is executed for every action.
 * We use it to pass the location of the token
 * back to the bison parser...
 */
#define YY_USER_ACTION { 					\
	yylloc.first_line = yylloc.last_line = yylineno;	\
	yylloc.first_column = yylloc.last_column = 0;		\
	}


/* Since this lexical parser we defined only works in ASCII based
 * systems, we might as well make sure it is being compiled on
 * one...
 * Lets check a few random characters...
 */
#if (('a' != 0x61) || ('A' != 0x41) || ('z' != 0x7A) || ('Z' != 0x5A) || \
     ('0' != 0x30) || ('9' != 0x39) || ('(' != 0x28) || ('[' != 0x5B))
#error This lexical analyser is not portable to a non ASCII based system.
#endif


/* Function only called from within flex, but defined
 * in iec.y!
 * We declare it here...
 *
 * Search for a symbol in either of the two symbol tables
 * and return the token id of the first symbol found.
 * Searches first in the variables, and only if not found
 * does it continue searching in the library elements
 */
//token_id_t get_identifier_token(const char *identifier_str);
int get_identifier_token(const char *identifier_str);
%}


/***************************************************/
/* Forward Declaration of functions defined later. */
/***************************************************/

%{
/* return all the text in the current token back to the input stream. */
void unput_text(unsigned int n);
%}



/****************************/
/* Lexical Parser States... */
/****************************/

/* NOTE: Our psrser can parse st or il code, intermixed
 *       within the same file.
 *       With IL we come across the issue of the EOL (end of line) token.
 *       ST, and the declaration parts of IL do not use this token!
 *       If the lexical analyser were to issue this token during ST
 *       language parsing, or during the declaration of data types,
 *       function headers, etc. in IL, the syntax parser would crash.
 *
 *       We can solve this issue using one of three methods:
 *        (1) Augment all the syntax that does not accept the EOL
 *            token to simply ignore it. This makes the syntax
 *            definition (in iec.y) very cluttered!
 *        (2) Let the lexical parser figure out which language
 *            it is parsing, and decide whether or not to issue
 *            the EOL token. This requires the lexical parser
 *            to have knowledge of the syntax!, making for a poor
 *            overall organisation of the code. It would also make it
 *            very difficult to understand the lexical parser as it
 *            would use several states, and a state machine to transition
 *            between the states. The state transitions would be
 *            intermingled with the lexical parser defintion!
 *        (3) Use a mixture of (1) and (2). The lexical analyser
 *            merely distinguishes between function headers and function
 *            bodies, but no longer makes a distinction between il and
 *            st language bodies. When parsing a body, it will return
 *            the EOL token. In other states '\n' will be ignored as
 *            whitespace.
 *            The ST language syntax has been augmented in the syntax
 *            parser configuration to ignore any EOL tokens that it may
 *            come across!
 *            This option has both drawbacks of option (1) and (2), but
 *            much less intensely.
 *            The syntax that gets cluttered is limited to the ST statements
 *            (which is rather limited, compared to the function headers and
 *            data type declarations, etc...), while the state machine in
 *            the lexical parser becomes very simple. All state transitions
 *            can be handled within the lexical parser by itself, and can be
 *            easily identified. Thus knowledge of the syntax required by
 *            the lexical parser is very limited!
 *
 * Amazingly enough, I (Mario) got to implement option (3)
 * at first, requiring two basic states, decl and body.
 * The lexical parser will enter the body state when
 * it is parsing the body of a function/program/function block. The
 * state transition is done when we find a VAR_END that is not followed
 * by a VAR! This is the syntax knowledge that gets included in the
 * lexical analyser with this option!
 * Unfortunately, getting the st syntax parser to ignore EOL anywhere
 * where they might appear leads to conflicts. This is due to the fact
 * that the syntax parser uses the single look-ahead token to remove
 * possible conflicts. When we insert a possible EOL, the single
 * look ahead token becomes the EOL, which means the potential conflicts
 * could no longer be resolved.
 * Removing these conflicts would make the st syntax parser very convoluted,
 * and adding the extraneous EOL would make it very cluttered.
 * This option was therefore dropped in favour of another!
 *
 * I ended up implementing (2). Unfortunately the lexical analyser can
 * not easily distinguish between il and st code, since function
 * calls in il are very similar to function block calls in st.
 * We therefore use an extra 'body' state. When the lexical parser
 * finds that last END_VAR, it enters the body state. This state
 * must figure out what language is being parsed from the first few
 * tokens, and switch to the correct state (st or il) according to the
 * language. This means that we insert quite a bit of knowledge of the
 * syntax of the languages into the lexical parser. This is ugly, but it
 * works, and at least it is possible to keep all the state changes together
 * to make it easier to remove them later on if need be.
 * The body state returns any matched text back to the buffer with unput(),
 * to be later matched correctly by the apropriate language parser (st or il).
 * The state machine has 6 possible states (INITIAL, config, decl, body, st, il)
 * Possible state changes are:
 *   INITIAL -> decl_state (when a FUNCTION, FUNCTION_BLOCK, or PROGRAM is found,
 *                    and followed by a VAR declaration)
 *   INITIAL -> il_st_state (when a FUNCTION, FUNCTION_BLOCK, or PROGRAM is found,
 *                    and _not_ followed by a VAR declaration)
 *   INITIAL -> config_state (when a CONFIGURATION is found)
 *   decl_state    -> il_st_state (when the last END_VAR is found, i.e. the function body starts)
 *   il_st_state   -> sfc_state (when it figures out it is parsing sfc language)
 *   il_st_state   -> st_state (when it figures out it is parsing st language)
 *   il_st_state   -> il_state (when it figures out it is parsing il language)
 *   decl_state    -> INITIAL (when a END_FUNCTION, END_FUNCTION_BLOCK, or END_PROGRAM is found)
 *   st_state      -> INITIAL (when a END_FUNCTION, END_FUNCTION_BLOCK, or END_PROGRAM is found)
 *   sfc_state     -> INITIAL (when a END_FUNCTION, END_FUNCTION_BLOCK, or END_PROGRAM is found)
 *   il_state      -> INITIAL (when a END_FUNCTION, END_FUNCTION_BLOCK, or END_PROGRAM is found)
 *   config_state  -> INITIAL (when a END_CONFIGURATION is found)
 */
/* we are parsing a configuration. */
%s config_state

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

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

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

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

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



/*******************/
/* File #include's */
/*******************/

/* We extend the IEC 61131-3 standard syntax to allow inclusion
 * of other files, using the IEC 61131-3 pragma directive...
 * The accepted syntax is:
 *  {#include "<filename>"}
 */

/* the "include" states are used for picking up the name of an include file */
%x include_beg
%x include_filename
%x include_end


file_include_pragma_filename	[^\"]*
file_include_pragma_beg		"{#include"{st_whitespace_only}\"
file_include_pragma_end		\"{st_whitespace_only}"}"
file_include_pragma			{file_include_pragma_beg}{file_include_pragma_filename}{file_include_pragma_end}


%{
#define MAX_INCLUDE_DEPTH 16

typedef struct {
	  YY_BUFFER_STATE buffer_state;
	  int lineno;
	  const char *filename;
	} include_stack_t;

include_stack_t include_stack[MAX_INCLUDE_DEPTH];
int include_stack_ptr = 0;

const char *INCLUDE_DIRECTORIES[] = {
	DEFAULT_LIBDIR,
	".",
	"/lib",
	"/usr/lib",
	"/usr/lib/iec",
	NULL /* must end with NULL!! */
	};

%}



/*****************************/
/* Prelimenary constructs... */
/*****************************/


/* A pragma... */

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

/* NOTE: this seemingly unnecessary complex definition is required
 *       to be able to eat up comments such as:
 *          '(* Testing... ! ***** ******)'
 *       without using the trailing context command in flex (/{context})
 *       since {comment} itself will later be used with
 *       trailing context ({comment}/{context})
 */
not_asterisk				[^*]
not_close_parenthesis_nor_asterisk	[^*)]
asterisk				"*"
comment_text		{not_asterisk}|(({asterisk}+){not_close_parenthesis_nor_asterisk})

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


/*
3.1 Whitespace
 (NOTE: Whitespace IS clearly defined, to include newline!!! See section 2.1.4!!!)
 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.).
 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.
 On the other hand, some examples that come in a non-normative annex of the specification allow function declarations to span multiple3.1 Whitespace
 (NOTE: Whitespace IS clearly defined, to include newline!!! See section 2.1.4!!!)
 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.).
 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.
 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.
 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.
*/
/* NOTE: Our definition of whitespace will only work in ASCII!
 *
 *       Since the IL language needs to know the location of newline
 *       (token EOL -> '\n' ), we need one definition of whitespace
 *       for each language...
 */
/*
 * NOTE: we cannot use
 *         st_whitespace	[:space:]*
 *       since we use {st_whitespace} as trailing context. In our case
 *       this would not constitute "dangerous trailing context", but the
 *       lexical generator (i.e. flex) does not know this (since it does
 *       not know which characters belong to the set [:space:]), and will
 *       generate a "dangerous trailing context" warning!
 *       We use this alternative just to stop the flex utility from
 *       generating the invalid (in this case) warning...
 */

st_whitespace_only	[ \f\n\r\t\v]*
il_whitespace_only	[ \f\r\t\v]*

st_whitespace_text	{st_whitespace_only}|{comment}|{pragma}
il_whitespace_text	{il_whitespace_only}|{comment}|{pragma}

st_whitespace	{st_whitespace_text}*
il_whitespace	{il_whitespace_text}*

st_whitespace_text_no_pragma	{st_whitespace_only}|{comment}
il_whitespace_text_no_pragma	{il_whitespace_only}|{comment}

st_whitespace_no_pragma	{st_whitespace_text_no_pragma}*
il_whitespace_no_pragma	{il_whitespace_text_no_pragma}*

qualified_identifier	{identifier}(\.{identifier})?



/*****************************************/
/* B.1.1 Letters, digits and identifiers */
/*****************************************/
/* NOTE: The following definitions only work if the host computer
 *       is using the ASCII maping. For e.g., with EBCDIC [A-Z]
 *       contains non-alphabetic characters!
 *       The correct way of doing it would be to use
 *       the [:upper:] etc... definitions.
 *
 *       Unfortunately, further on we need all printable
 *       characters (i.e. [:print:]), but excluding '$'.
 *       Flex does not allow sets to be composed by excluding
 *       elements. Sets may only be constructed by adding new
 *       elements, which means that we have to revert to
 *       [\x20\x21\x23\x25\x26\x28-x7E] for the definition
 *       of the printable characters with the required exceptions.
 *       The above also implies the use of ASCII, but now we have
 *       no way to work around it|
 *
 *       The conclusion is that our parser is limited to ASCII
 *       based host computers!!
 */
letter		[A-Za-z]
digit		[0-9]
octal_digit	[0-7]
hex_digit	{digit}|[A-F]
identifier	({letter}|(_({letter}|{digit})))((_?({letter}|{digit}))*)


/*******************/
/* B.1.2 Constants */
/*******************/

/******************************/
/* B.1.2.1   Numeric literals */
/******************************/
integer         {digit}((_?{digit})*)
binary_integer  2#{bit}((_?{bit})*)
bit		[0-1]
octal_integer   8#{octal_digit}((_?{octal_digit})*)
hex_integer     16#{hex_digit}((_?{hex_digit})*)
exponent        [Ee]([+-]?){integer}
/* The correct definition for real would be:
 * real		{integer}\.{integer}({exponent}?)
 *
 * Unfortunately, the spec also defines fixed_point (B 1.2.3.1) as:
 * fixed_point		{integer}\.{integer}
 *
 * This means that {integer}\.{integer} could be interpreted
 * as either a fixed_point or a real.
 * I have opted to interpret {integer}\.{integer} as a fixed_point.
 * In order to do this, the definition of real has been changed to:
 * real		{integer}\.{integer}{exponent}
 *
 * This means that the syntax parser now needs to define a real to be
 * either a real_token or a fixed_point_token!
 */
real		{integer}\.{integer}{exponent}


/*******************************/
/* B.1.2.2   Character Strings */
/*******************************/
/*
common_character_representation :=
<any printable character except '$', '"' or "'">
|'$$'
|'$L'|'$N'|'$P'|'$R'|'$T'
|'$l'|'$n'|'$p'|'$r'|'$t'

NOTE: 	$ = 0x24
	" = 0x22
	' = 0x27

	printable chars in ASCII: 0x20-0x7E
*/

esc_char_u		$L|$N|$P|$R|$T
esc_char_l		$l|$n|$p|$r|$t
esc_char		$$|{esc_char_u}|{esc_char_l}
double_byte_char	(${hex_digit}{hex_digit}{hex_digit}{hex_digit})
single_byte_char	(${hex_digit}{hex_digit})

/* WARNING:
 * This definition is only valid in ASCII...
 *
 * Flex includes the function print_char() that defines
 * all printable characters portably (i.e. whatever character
 * encoding is currently being used , ASCII, EBCDIC, etc...)
 * Unfortunately, we cannot generate the definition of
 * common_character_representation portably, since flex
 * does not allow definition of sets by subtracting
 * elements in one set from another set.
 * This means we must build up the defintion of
 * common_character_representation using only set addition,
 * which leaves us with the only choice of defining the
 * characters non-portably...
 */
common_character_representation		[\x20\x21\x23\x25\x26\x28-\x7E]|{esc_char}
double_byte_character_representation 	$\"|'|{double_byte_char}|{common_character_representation}
single_byte_character_representation 	$'|\"|{single_byte_char}|{common_character_representation}


double_byte_character_string	\"({double_byte_character_representation}*)\"
single_byte_character_string	'({single_byte_character_representation}*)'


/************************/
/* B 1.2.3.1 - Duration */
/************************/
fixed_point		{integer}\.{integer}

fixed_point_d		{fixed_point}d
integer_d		{integer}d

fixed_point_h		{fixed_point}h
integer_h		{integer}h

fixed_point_m		{fixed_point}m
integer_m		{integer}m

fixed_point_s		{fixed_point}s
integer_s		{integer}s

fixed_point_ms		{fixed_point}ms
integer_ms		{integer}ms


/********************************************/
/* B.1.4.1   Directly Represented Variables */
/********************************************/
/* The correct definition, if the standard were to be followed... */

location_prefix			[IQM]
size_prefix			[XBWDL]
direct_variable_standard	%{location_prefix}({size_prefix}?){integer}((.{integer})*)


/* For the MatPLC, we will accept %<identifier>
 * as a direct variable, this being mapped onto the MatPLC point
 * named <identifier>
 */
/* TODO: we should not restrict it to only the accepted syntax
 * of <identifier> as specified by the standard. MatPLC point names
 * have a more permissive syntax.
 *
 * e.g. "P__234"
 *    Is a valid MatPLC point name, but not a valid <identifier> !!
 *    The same happens with names such as "333", "349+23", etc...
 *    How can we handle these more expressive names in our case?
 *    Remember that some direct variable may remain anonymous, with
 *    declarations such as:
 *    VAR
 *       AT %I3 : BYTE := 255;
 *    END_VAR
 *    in which case we are currently using "%I3" as the variable
 *    name.
 */
direct_variable_matplc		%{identifier}

direct_variable			{direct_variable_standard}|{direct_variable_matplc}

/******************************************/
/* B 1.4.3 - Declaration & Initialisation */
/******************************************/
incompl_location	%[IQM]\*




%%
	/* fprintf(stderr, "flex: state %d\n", YY_START); */

	/*****************************************************/
	/*****************************************************/
	/*****************************************************/
	/*****                                           *****/
	/*****                                           *****/
	/*****   F I R S T    T H I N G S    F I R S T   *****/
	/*****                                           *****/
	/*****                                           *****/
	/*****************************************************/
	/*****************************************************/
	/*****************************************************/

	if (get_goto_body_state()) {
	  yy_push_state(il_st_state);
	  rst_goto_body_state();
	}

	/*********************************/
	/* Handle the pragmas!     */
	/*********************************/

	/* We start off by searching for the pragmas we handle in the lexical parser. */
<INITIAL>{file_include_pragma}	unput_text(0); yy_push_state(include_beg);

	/* Any other pragma we find, we just pass it up to the syntax parser...   */
	/* Note that the <il_st_state> state is exclusive, so we have to include it here too. */
{pragma}	{/* return the pragmma without the enclosing '{' and '}' */
		 yytext[strlen(yytext)-1] = '\0';
		 yylval.ID=strdup(yytext+1);
		 return pragma_token;
		}
<il_st_state>{pragma} {/* return the pragmma without the enclosing '{' and '}' */
		 yytext[strlen(yytext)-1] = '\0';
		 yylval.ID=strdup(yytext+1);
		 return pragma_token;
		}


	/*********************************/
	/* Handle the file includes!     */
	/*********************************/
<include_beg>{file_include_pragma_beg}	BEGIN(include_filename);

<include_filename>{file_include_pragma_filename}	{
			  /* got the include file name */
			  int i;

			  if (include_stack_ptr >= MAX_INCLUDE_DEPTH) {
			    fprintf(stderr, "Includes nested too deeply\n");
			    exit( 1 );
			  }

			  (include_stack[include_stack_ptr]).buffer_state = YY_CURRENT_BUFFER;
			  (include_stack[include_stack_ptr]).lineno = yylineno;
			  (include_stack[include_stack_ptr]).filename = current_filename;
			  include_stack_ptr++;
			  yylineno = 1;
			  current_filename = strdup(yytext);

			  for (i = 0, yyin = NULL; (INCLUDE_DIRECTORIES[i] != NULL) && (yyin == NULL); i++) {
			    char *full_name = strdup3(INCLUDE_DIRECTORIES[i], "/", yytext);
			    if (full_name == NULL) {
			      fprintf(stderr, "Out of memory!\n");
			      exit( 1 );
			    }
			    yyin = fopen(full_name, "r");
			    free(full_name);
			  }

			  if (!yyin) {
			    fprintf(stderr, "Error opening included file %s\n", yytext);
			    exit( 1 );
			  }

			  /* switch input buffer to new file... */
			  yy_switch_to_buffer(yy_create_buffer(yyin, YY_BUF_SIZE));
			  /* switch to whatever state was active before the include file */
			  yy_pop_state();
			  /* now process the new file... */
			}


<<EOF>>			{
			  if (--include_stack_ptr < 0) {
			    yyterminate();
			  } else {
			    yy_delete_buffer(YY_CURRENT_BUFFER);
			    yy_switch_to_buffer((include_stack[include_stack_ptr]).buffer_state);
			    yylineno = include_stack[include_stack_ptr].lineno;
			      /* removing constness of char *. This is safe actually,
			       * since the only real const char * that is stored on the stack is
			       * the first one (i.e. the one that gets stored in include_stack[0],
			       * which is never free'd!
			       */
			    free((char *)current_filename);
			    current_filename = include_stack[include_stack_ptr].filename;
			    yy_push_state(include_end);
			  }
			}

<include_end>{file_include_pragma_end}	yy_pop_state();


	/*********************************/
	/* Handle all the state changes! */
	/*********************************/

	/* INITIAL -> decl_state */
<INITIAL>{
	/* NOTE: how about functions that do not declare variables, and go directly to the il_st_state???
	 *      - According to Section 2.5.1.3 (Function Declaration), item 2 in the list, a FUNCTION
	 *        must have at least one input argument, so a correct declaration will have at least
	 *        one VAR_INPUT ... VAR_END construct!
	 *      - According to Section 2.5.2.2 (Function Block Declaration), a FUNCTION_BLOCK
	 *        must have at least one input argument, so a correct declaration will have at least
	 *        one VAR_INPUT ... VAR_END construct!
	 *      - According to Section 2.5.3 (Programs), a PROGRAM must have at least one input
	 *        argument, so a correct declaration will have at least one VAR_INPUT ... VAR_END
	 *        construct!
	 *
	 *       All the above means that we needn't worry about PROGRAMs, FUNCTIONs or
	 *       FUNCTION_BLOCKs that do not have at least one VAR_END before the il_st_state.
	 *       If the code has an error, and no VAR_END before the body, we will simply
	 *       continue in the <decl_state> state, untill the end of the FUNCTION, FUNCTION_BLOCK
	 *       or PROGAM.
	 */
FUNCTION				BEGIN(decl_state); return FUNCTION;
FUNCTION_BLOCK				BEGIN(decl_state); return FUNCTION_BLOCK;
PROGRAM					BEGIN(decl_state); return PROGRAM;
CONFIGURATION				BEGIN(config_state); return CONFIGURATION;
}

	/* INITIAL -> il_st_state */
	/* required if the function, program, etc.. has no VAR block! */
	/* We comment it out since the standard does not allow this.  */
	/* NOTE: Even if we were to include the following code, it    */
	/*       would have no effect whatsoever since the above      */
	/*       rules will take precendence!                         */
	/*
<INITIAL>{
FUNCTION	BEGIN(il_st_state); return FUNCTION;
FUNCTION_BLOCK	BEGIN(il_st_state); return FUNCTION_BLOCK;
PROGRAM		BEGIN(il_st_state); return PROGRAM;
}
	*/

	/* decl_state -> (il_st_state | sfc_state) */
<decl_state>{
END_VAR{st_whitespace}VAR		{unput_text(strlen("END_VAR")); 
					 return END_VAR;
					}
END_VAR{st_whitespace}INITIAL_STEP	{unput_text(strlen("END_VAR")); 
					 yy_push_state(sfc_state); 
					 return END_VAR;
					}
END_VAR{st_whitespace}			{unput_text(strlen("END_VAR")); 
					 cmd_goto_body_state(); 
					 return END_VAR;
					}
}

	/* il_st_state -> (il_state | st_state) */
<il_st_state>{
{st_whitespace_no_pragma}			/* Eat any whitespace */
{qualified_identifier}{st_whitespace}":="	unput_text(0); BEGIN(st_state);
{qualified_identifier}"["			unput_text(0); BEGIN(st_state);

RETURN						unput_text(0); BEGIN(st_state);
IF						unput_text(0); BEGIN(st_state);
CASE						unput_text(0); BEGIN(st_state);
FOR						unput_text(0); BEGIN(st_state);
WHILE						unput_text(0); BEGIN(st_state);
REPEAT						unput_text(0); BEGIN(st_state);
EXIT						unput_text(0); BEGIN(st_state);
	/* ':=' occurs only in transitions, and not Function or FB bodies! */
:=						unput_text(0); BEGIN(st_state);  


{identifier}	{int token = get_identifier_token(yytext);
		 if (token == prev_declared_fb_name_token) {
		   /* the code has a call to a function block */
		   BEGIN(st_state);
		 } else {
		   BEGIN(il_state);
		 }
		 unput_text(0);
		}
.		unput_text(0); BEGIN(il_state);
}	/* end of il_st_state lexical parser */

	/* (il_state | st_state) -> $previous_state (decl_state or sfc_state) */
<il_state,st_state>{
END_FUNCTION		yy_pop_state(); unput_text(0);
END_FUNCTION_BLOCK	yy_pop_state(); unput_text(0);
END_PROGRAM		yy_pop_state(); unput_text(0);
END_TRANSITION		yy_pop_state(); unput_text(0);
END_ACTION		yy_pop_state(); unput_text(0);
}

	/* sfc_state -> INITIAL */
<sfc_state>{
END_FUNCTION		yy_pop_state(); unput_text(0);
END_FUNCTION_BLOCK	yy_pop_state(); unput_text(0);
END_PROGRAM		yy_pop_state(); unput_text(0);
}

	/* decl_state -> INITIAL */
<decl_state>{
END_FUNCTION		BEGIN(INITIAL); return END_FUNCTION;
END_FUNCTION_BLOCK	BEGIN(INITIAL); return END_FUNCTION_BLOCK;
END_PROGRAM		BEGIN(INITIAL); return END_PROGRAM;
}
	/* config -> INITIAL */
END_CONFIGURATION	BEGIN(INITIAL); return END_CONFIGURATION;



	/***************************************/
	/* Next is to to remove all whitespace */
	/***************************************/
	/* NOTE: pragmas are handled right at the beginning... */

<INITIAL,config_state,decl_state,st_state,sfc_state>{st_whitespace_no_pragma}	/* Eat any whitespace */
<il_state>{il_whitespace_no_pragma}		/* Eat any whitespace */


	/*****************************************/
	/* B.1.1 Letters, digits and identifiers */
	/*****************************************/
	/* NOTE: 'R1', 'IN', etc... are IL operators, and therefore tokens
	 *       On the other hand, the spec does not define them as keywords,
	 *       which means they may be re-used for variable names, etc...!
	 *       The syntax parser already caters for the possibility of these
	 *       tokens being used for variable names in their declarations.
	 *       When they are declared, they will be added to the variable symbol table!
	 *       Further appearances of these tokens must no longer be parsed
	 *       as R1_tokens etc..., but rather as variable_name_tokens!
	 *
	 *       That is why the first thing we do with identifiers, even before
	 *       checking whether they may be a 'keyword', is to check whether
	 *       they have been previously declared as a variable name,
	 *
	 *       However, we have a dilema! Should we here also check for
	 *       prev_declared_derived_function_name_token?
	 *       If we do, then the 'MOD' default library function (defined in
	 *       the standard) will always be returned as a function name, and
	 *       it will therefore not be possible to use it as an operator as 
	 *       in the following ST expression 'X := Y MOD Z;' !
	 *       If we don't, then even it will not be possible to use 'MOD'
	 *       as a funtion as in 'X := MOD(Y, Z);'
	 *       We solve this by NOT testing for function names here, and
	 *       handling this function and keyword clash in bison!
	 */
{identifier} 	{int token = get_identifier_token(yytext);
		 if ((token == prev_declared_variable_name_token) ||
//		     (token == prev_declared_derived_function_name_token) || // DO NOT add this condition!
		     (token == prev_declared_fb_name_token)) {
		 /*
		 if (token != identifier_token)
		 */
		 /* NOTE: if we replace the above uncommented conditions with
                  *       the simple test of (token != identifier_token), then 
                  *       'MOD' et al must be removed from the 
                  *       library_symbol_table as a default function name!
		  */
		   yylval.ID=strdup(yytext);
		   return token;
		 }
		 /* otherwise, leave it for the other lexical parser rules... */
		 REJECT;
		}


	/******************************************************/
	/******************************************************/
	/******************************************************/
	/*****                                            *****/
	/*****                                            *****/
	/*****   N O W    D O   T H E   K E Y W O R D S   *****/
	/*****                                            *****/
	/*****                                            *****/
	/******************************************************/
	/******************************************************/
	/******************************************************/


EN	return EN;
ENO	return ENO;


	/******************************/
	/* B 1.2.1 - Numeric Literals */
	/******************************/
TRUE		return TRUE;
BOOL#1  	return TRUE;
FALSE		return FALSE;
BOOL#0  	return FALSE;


	/************************/
	/* B 1.2.3.1 - Duration */
	/************************/
t#		return T_SHARP;
T#		return T_SHARP;
TIME		return TIME;


	/************************************/
	/* B 1.2.3.2 - Time of day and Date */
	/************************************/
TIME_OF_DAY	return TIME_OF_DAY;
TOD		return TIME_OF_DAY;
DATE		return DATE;
d#		return D_SHARP;
D#		return D_SHARP;
DATE_AND_TIME	return DATE_AND_TIME;
DT		return DATE_AND_TIME;


	/***********************************/
	/* B 1.3.1 - Elementary Data Types */
	/***********************************/
BYTE		return BYTE;
WORD		return WORD;
DWORD		return DWORD;
LWORD		return LWORD;


	/********************************/
	/* B 1.3.2 - Generic data types */
	/********************************/
	/* Strangely, the following symbols do not seem to be required! */
	/* But we include them so they become reserved words, and do not
	 * get passed up to bison as an identifier...
	 */
ANY		return ANY;
ANY_DERIVED	return ANY_DERIVED;
ANY_ELEMENTARY	return ANY_ELEMENTARY;
ANY_MAGNITUDE	return ANY_MAGNITUDE;
ANY_NUM		return ANY_NUM;
ANY_REAL	return ANY_REAL;
ANY_INT		return ANY_INT;
ANY_BIT		return ANY_BIT;
ANY_STRING	return ANY_STRING;
ANY_DATE	return ANY_DATE;


	/********************************/
	/* B 1.3.3 - Derived data types */
	/********************************/
":="		return ASSIGN;
".."		return DOTDOT;
TYPE		return TYPE;
END_TYPE	return END_TYPE;
ARRAY		return ARRAY;
OF		return OF;
STRUCT		return STRUCT;
END_STRUCT	return END_STRUCT;


	/*********************/
	/* B 1.4 - Variables */
	/*********************/
REAL		return REAL;
LREAL		return LREAL;

SINT		return SINT;
INT		return INT;
DINT		return DINT;
LINT		return LINT;

USINT		return USINT;
UINT		return UINT;
UDINT		return UDINT;
ULINT		return ULINT;


WSTRING		return WSTRING;
STRING		return STRING;
BOOL		return BOOL;

TIME		return TIME;
DATE		return DATE;
DT		return DT;
TOD		return TOD;
DATE_AND_TIME	return DATE_AND_TIME;
TIME_OF_DAY	return TIME_OF_DAY;


	/******************************************/
	/* B 1.4.3 - Declaration & Initialisation */
	/******************************************/
VAR_INPUT	return VAR_INPUT;
VAR_OUTPUT	return VAR_OUTPUT;
VAR_IN_OUT	return VAR_IN_OUT;
VAR_EXTERNAL	return VAR_EXTERNAL;
VAR_GLOBAL	return VAR_GLOBAL;
END_VAR		return END_VAR;
RETAIN		return RETAIN;
NON_RETAIN	return NON_RETAIN;
R_EDGE		return R_EDGE;
F_EDGE		return F_EDGE;
AT		return AT;


	/***********************/
	/* B 1.5.1 - Functions */
	/***********************/
FUNCTION	return FUNCTION;
END_FUNCTION	return END_FUNCTION;
VAR		return VAR;
CONSTANT	return CONSTANT;


	/*****************************/
	/* B 1.5.2 - Function Blocks */
	/*****************************/
FUNCTION_BLOCK		return FUNCTION_BLOCK;
END_FUNCTION_BLOCK	return END_FUNCTION_BLOCK;
VAR_TEMP		return VAR_TEMP;
VAR			return VAR;
NON_RETAIN		return NON_RETAIN;
END_VAR			return END_VAR;


	/**********************/
	/* B 1.5.3 - Programs */
	/**********************/
PROGRAM		return PROGRAM;
END_PROGRAM	return END_PROGRAM;


	/********************************************/
	/* B 1.6 Sequential Function Chart elements */
	/********************************************/
	/* NOTE: the following identifiers/tokens clash with the R and S IL operators, as well
	.* as other identifiers that may be used as variable names inside IL and ST programs.
	 * They will have to be handled when we include parsing of SFC... For now, simply
	 * ignore them!
	 */
	 
<sfc_state>{
ACTION		return ACTION;
END_ACTION	return END_ACTION;

TRANSITION	return TRANSITION;
END_TRANSITION	return END_TRANSITION;
FROM		return FROM;
TO		return TO;
PRIORITY	return PRIORITY;

INITIAL_STEP	return INITIAL_STEP;
STEP		return STEP;
END_STEP	return END_STEP;

L		return L;
D		return D;
SD		return SD;
DS		return DS;
SL		return SL;

N		return N;
P		return P;

R		return R;
S		return S;
}


	/********************************/
	/* B 1.7 Configuration elements */
	/********************************/
CONFIGURATION		return CONFIGURATION;
END_CONFIGURATION	return END_CONFIGURATION;
TASK			return TASK;
RESOURCE		return RESOURCE;
ON			return ON;
END_RESOURCE		return END_RESOURCE;
VAR_CONFIG		return VAR_CONFIG;
VAR_ACCESS		return VAR_ACCESS;
END_VAR			return END_VAR;
WITH			return WITH;
PROGRAM			return PROGRAM;
RETAIN			return RETAIN;
NON_RETAIN		return NON_RETAIN;
PRIORITY		return PRIORITY;
SINGLE			return SINGLE;
INTERVAL		return INTERVAL;
READ_WRITE		return READ_WRITE;
READ_ONLY		return READ_ONLY;


	/***********************************/
	/* B 2.1 Instructions and Operands */
	/***********************************/
<il_state>\n		return EOL;


	/*******************/
	/* B 2.2 Operators */
	/*******************/
	/* NOTE: we can't have flex return the same token for
	 *       ANDN and &N, neither for AND and &, since
	 *       AND and ANDN are considered valid variable
	 *       function or functionblock type names!
	 *       This means that the parser may decide that the
	 *       AND or ANDN strings found in the source code
	 *       are being used as variable names
	 *       and not as operators, and will therefore transform
	 *       these tokens into indentifier tokens!
	 *       We can't have the parser thinking that the source
	 *       code contained the string AND (which may be interpreted
	 *       as a vairable name) when in reality the source code
	 *       merely contained the character &, so we use two
	 *       different tokens for & and AND (and similarly
	 *       ANDN and &N)!
	 */
LD		return LD;
LDN		return LDN;
ST		return ST;
STN		return STN;
NOT		return NOT;
S		return S;
R		return R;
S1		return S1;
R1		return R1;
CLK		return CLK;
CU		return CU;
CD		return CD;
PV		return PV;
IN		return IN;
PT		return PT;
AND		return AND;
&		return AND2;
OR		return OR;
XOR		return XOR;
ANDN		return ANDN;
&N		return ANDN2;
ORN		return ORN;
XORN		return XORN;
ADD		return ADD;
SUB		return SUB;
MUL		return MUL;
DIV		return DIV;
MOD		return MOD;
GT		return GT;
GE		return GE;
EQ		return EQ;
LT		return LT;
LE		return LE;
NE		return NE;
CAL		return CAL;
CALC		return CALC;
CALCN		return CALCN;
RET		return RET;
RETC		return RETC;
RETCN		return RETCN;
JMP		return JMP;
JMPC		return JMPC;
JMPCN		return JMPCN;


	/***********************/
	/* B 3.1 - Expressions */
	/***********************/
"**"		return OPER_EXP;
"<>"		return OPER_NE;
">="		return OPER_GE;
"<="		return OPER_LE;
AND		return AND;
XOR		return XOR;
OR		return OR;
NOT		return NOT;
MOD		return MOD;


	/*****************************************/
	/* B 3.2.2 Subprogram Control Statements */
	/*****************************************/
:=		return ASSIGN;
=>		return SENDTO;
RETURN		return RETURN;


	/********************************/
	/* B 3.2.3 Selection Statements */
	/********************************/
IF		return IF;
THEN		return THEN;
ELSIF		return ELSIF;
ELSE		return ELSE;
END_IF		return END_IF;

CASE		return CASE;
OF		return OF;
ELSE		return ELSE;
END_CASE	return END_CASE;


	/********************************/
	/* B 3.2.4 Iteration Statements */
	/********************************/
FOR		return FOR;
TO		return TO;
BY		return BY;
DO		return DO;
END_FOR		return END_FOR;

WHILE		return WHILE;
DO		return DO;
END_WHILE	return END_WHILE;

REPEAT		return REPEAT;
UNTIL		return UNTIL;
END_REPEAT	return END_REPEAT;

EXIT		return EXIT;





	/********************************************************/
	/********************************************************/
	/********************************************************/
	/*****                                              *****/
	/*****                                              *****/
	/*****  N O W    W O R K    W I T H    V A L U E S  *****/
	/*****                                              *****/
	/*****                                              *****/
	/********************************************************/
	/********************************************************/
	/********************************************************/


	/********************************************/
	/* B.1.4.1   Directly Represented Variables */
	/********************************************/
{direct_variable}	{yylval.ID=strdup(yytext); return direct_variable_token;}


	/******************************************/
	/* B 1.4.3 - Declaration & Initialisation */
	/******************************************/
{incompl_location}	{yylval.ID=strdup(yytext); return incompl_location_token;}


	/************************/
	/* B 1.2.3.1 - Duration */
	/************************/
{fixed_point}		{yylval.ID=strdup(yytext); return fixed_point_token;}

{fixed_point_d}		{yylval.ID=strdup(yytext); yylval.ID[yyleng-1] = '\0'; return fixed_point_d_token;}
{integer_d}		{yylval.ID=strdup(yytext); yylval.ID[yyleng-1] = '\0'; return integer_d_token;}

{fixed_point_h}		{yylval.ID=strdup(yytext); yylval.ID[yyleng-1] = '\0'; return fixed_point_h_token;}
{integer_h}		{yylval.ID=strdup(yytext); yylval.ID[yyleng-1] = '\0'; return integer_h_token;}

{fixed_point_m}		{yylval.ID=strdup(yytext); yylval.ID[yyleng-1] = '\0'; return fixed_point_m_token;}
{integer_m}		{yylval.ID=strdup(yytext); yylval.ID[yyleng-1] = '\0'; return integer_m_token;}

{fixed_point_s}		{yylval.ID=strdup(yytext); yylval.ID[yyleng-1] = '\0'; return fixed_point_s_token;}
{integer_s}		{yylval.ID=strdup(yytext); yylval.ID[yyleng-1] = '\0'; return integer_s_token;}

{fixed_point_ms}	{yylval.ID=strdup(yytext); yylval.ID[yyleng-2] = '\0'; return fixed_point_ms_token;}
{integer_ms}		{yylval.ID=strdup(yytext); yylval.ID[yyleng-2] = '\0'; return integer_ms_token;}


	/*******************************/
	/* B.1.2.2   Character Strings */
	/*******************************/
{double_byte_character_string} {yylval.ID=strdup(yytext); return double_byte_character_string_token;}
{single_byte_character_string} {yylval.ID=strdup(yytext); return single_byte_character_string_token;}


	/******************************/
	/* B.1.2.1   Numeric literals */
	/******************************/
{integer}		{yylval.ID=strdup(yytext); return integer_token;}
{real}			{yylval.ID=strdup(yytext); return real_token;}
{binary_integer}	{yylval.ID=strdup(yytext); return binary_integer_token;}
{octal_integer} 	{yylval.ID=strdup(yytext); return octal_integer_token;}
{hex_integer} 		{yylval.ID=strdup(yytext); return hex_integer_token;}


	/*****************************************/
	/* B.1.1 Letters, digits and identifiers */
	/*****************************************/
<st_state>{identifier}/({st_whitespace})"=>"	{yylval.ID=strdup(yytext); return sendto_identifier_token;}
<il_state>{identifier}/({il_whitespace})"=>"	{yylval.ID=strdup(yytext); return sendto_identifier_token;}
{identifier} 				{yylval.ID=strdup(yytext);
					 /*printf("returning identifier...: %s, %d\n", yytext, get_identifier_token(yytext));*/
					 return get_identifier_token(yytext);}






	/************************************************/
	/************************************************/
	/************************************************/
	/*****                                      *****/
	/*****                                      *****/
	/*****   T H E    L E F T O V E R S . . .   *****/
	/*****                                      *****/
	/*****                                      *****/
	/************************************************/
	/************************************************/
	/************************************************/

	/* do the single character tokens...
	 *
	 *  e.g.:  ':'  '('  ')'  '+'  '*'  ...
	 */
.	{return yytext[0];}


%%


/***********************************/
/* Utility function definitions... */
/***********************************/

/* print the include file stack to stderr... */
void print_include_stack(void) {
  int i;

  if ((include_stack_ptr - 1) >= 0)
    fprintf (stderr, "in file "); 
  for (i = include_stack_ptr - 1; i >= 0; i--)
    fprintf (stderr, "included from file %s:%d\n", include_stack[i].filename, include_stack[i].lineno);
}


/* return all the text in the current token back to the input stream, except the first n chars. */
void unput_text(unsigned int n) {
  /* it seems that flex has a bug in that it will not correctly count the line numbers
   * if we return newlines back to the input stream. These newlines will be re-counted
   * a second time when they are processed again by flex.
   * We therefore determine how many newlines are in the text we are returning,
   * and decrement the line counter acordingly...
   */
  unsigned int i;

  for (i = n; i < strlen(yytext); i++)
    if (yytext[i] == '\n')
      yylineno--;

  /* now return all the text back to the input stream... */
  yyless(n);
}


/* Called by flex when it reaches the end-of-file */
int yywrap(void)
{
  /* We reached the end of the input file... */

  /* Should we continue with another file? */
  /* If so:
   *   open the new file...
   *   return 0;
   */

  /* to we stop processing...
   *
   *   return 1;
   */


  return 1;  /* Stop scanning at end of input file. */
}



/*************************************/
/* Include a main() function to test */
/* the token parsing by flex....     */
/*************************************/
#ifdef TEST_MAIN

#include "../util/symtable.hh"

yystype yylval;
YYLTYPE yylloc;

const char *current_filename;



int get_identifier_token(const char *identifier_str) {return 0;}



int main(int argc, char **argv) {

  FILE *in_file;
  int res;

  if (argc == 1) {
    /* Work as an interactive (command line) parser... */
    while((res=yylex()))
      fprintf(stderr, "(line %d)token: %d\n", yylineno, res);
  } else {
    /* Work as non-interactive (file) parser... */
    if((in_file = fopen(argv[1], "r")) == NULL) {
      char *errmsg = strdup2("Error opening main file ", argv[1]);
      perror(errmsg);
      free(errmsg);
      return -1;
    }

    /* parse the file... */
    yyin = in_file;
    current_filename = argv[1];
    while(1) {
      res=yylex();
      fprintf(stderr, "(line %d)token: %d (%s)\n", yylineno, res, yylval.ID);
    }
  }

  return 0;

}
#endif