3
$\begingroup$

I have a VHDL elaboration engine/simulator. As I understand it, the language syntax allows for ambiguities at syntax level. That is, an assignment

pin_value <= bus(5)

can be interpreted as picking a child of the bus by index. Here the bus is a signal (an object). However, it can also be that paranthis are applied to a type

int_signal <= integer(1.1)

which should be interpreted as type conversion.

I wonder. The elaborator should take the parse tree, instantiate objects and tie them together resolving the names. However, the parser has no idea if the prefix at the parensis is a type or array. So, it treats all parensis as indexed objects.

simple_assignment ::= target <= value_expression { , value_expression } 
value_expression ::= name | literal | function_call | type_conversion 
name ::= simple_name | indexed_name 
indexed_name ::= prefix ( expression { , expression } ) // example: REG_ARRAY(5)    
type_conversion ::= type_mark ( expression )

I do not see how can I distinguish between value_expression and type_conversion at syntactic level. My parser parses both as indexed_name and name resolution, when fails to find array object, falls back into type conversion. I am asking if such case analysis it the only way to handle the problem or more strighnforward approach exists that I am missing?

Improve this question
$\endgroup$
2
  • 1
    $\begingroup$ The ANTLR parser generator was originally designed to deal specifically with such semantic ambiguities. I'm sure that would solve all of your problems. $\endgroup$
    – Dave Clarke
    Commented Apr 22, 2014 at 21:06
  • 1
    $\begingroup$ Are prefix and type_mark tokens returned by the lexer? I think the answer to your question is going to be something to the effect that you have to keep a symbol table around while doing lexing. When you read in the next token you look it up in the symbol table, which tells you whether it is a prefix, a type_mark or something else. $\endgroup$
    – Wandering Logic
    Commented Apr 22, 2014 at 21:08

1 Answer 1

Reset to default
4
$\begingroup$

There is no reason to "distinguish between value_expression and type_conversion" since, according to the grammar a type_conversion is a value_expression.

You probably mean to distinguish between indexed_name and type_conversion ... and possibly also function_call, but you do not give its syntax, so I am not sure.

I do not know VHDL, but it may be that the syntax you have is the syntax used to explain the language to users, not the syntax actually used in the parser. The parser could simply use a grammar that does not distinguish between indexed_name and type_conversion, and leave the distinction for a later processing stage, when the lexical entities have been identified and their "nature" is known: array, type or function name.

Alternatively, and more likely, it is possible that symbol tables are built as the program is parsed, and when an identifier is found by the lexer (lexical analyser), the lexer will look in the table and will tell the parser whether it is a type_mark or a prefix (i.e., array identifier) before the parentheses. Then the parser can proceed with the proper rule for type_conversion or indexed_name.

Improve this answer
$\endgroup$
3
  • $\begingroup$ So, you say that the elaboration can be integrated into the parsing. That is a good argument. I actually see no reason to build the parse tree since it seems to me that VHDL can be elaborated in single pass. If it aids the parser, this is one additional argument to avoid creating extra structures. Thanks. $\endgroup$
    – Val
    Commented Apr 23, 2014 at 5:41
  • $\begingroup$ @Val There is no absolute rule on how to organize a compiler or interpreter. Most languages are built in such a way that lexical items can be associated with a prior definition allowing to know whatever is needed for parsing. This information is used by the lexer. What kind of information depends on the language. Building a parse tree is not usually an issue as grammars (hence parse-trees too) are often tortured to fit a parsing technique. What may be useful is building an abstract syntax tree (AST) that is close to the language semantics. But this may use lexer information (when possible). $\endgroup$
    – babou
    Commented Apr 23, 2014 at 8:50
  • $\begingroup$ @Val Note that it is possible for a language definition to allow for ambiguities that cannot be resolved by semantics. But then, the mabiguity must be detectable by the compiler and produce an error message, so that the programmer is required to add to the program appropriate information (such as type information) that will resolve the ambiguity (search the web with: ada ambiguity). This is not necessarily a syntactic ambiguity (what is syntactic?), but syntactic ambiguity could be treated the same way. Language designers tend to try avoiding it, though. $\endgroup$
    – babou
    Commented Apr 23, 2014 at 9:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.