VHDL Operator associativity (Quartus II parser bug?)

[Fons]

I am working on a compiler which generates VHDL and uses precedence
and associativity to generate the least parenthesis possible.

According to the LRM, "operators with the same precedence level are
associated with their
operands in textual order, from left to right."

More specifically, according to VHDL for Engineers (http://
books.google.com/books?id=7GKpXrMuZTIC&dq), the following two
expressions are equivalent:

a and not b or not a and b

((a and (not b)) or (not a)) and b

However, while Quartus II and Modelsim accept the second one, they
raise a parser error when trying to compile the first one.

If the "or" is changed with "and" the expression doesn't cause any
problems:

a and not b and not a and b

Can anyone confirm wether is a bug or the book is wrong?

Thanks.

 

[Andy]

I am working on a compiler which generates VHDL and uses precedence
and associativity to generate the least parenthesis possible.

According to the LRM, "operators with the same precedence level are
associated with their
operands in textual order, from left to right."

More specifically, according to VHDL for Engineers (http://
books.google.com/books?id=7GKpXrMuZTIC&dq), the following two
expressions are equivalent:

a and not b or not a and b

((a and (not b)) or (not a)) and b

However, while Quartus II and Modelsim accept the second one, they
raise a parser error when trying to compile the first one.

If the "or" is changed with "and" the expression doesn't cause any
problems:

a and not b and not a and b

Can anyone confirm wether is a bug or the book is wrong?

Thanks.

IINM, "and" and "or" operators are not allowed to be mixed without
parentheses in VHDL. This is from the heritage from ada.

Andy

 

[Mike Treseler]

More specifically, according to VHDL for Engineers (http://
books.google.com/books?id=7GKpXrMuZTIC&dq), the following two
expressions are equivalent:

a and not b or not a and b

^ Illegal
Have to finish the AND before
considering the lower precedence OR.

However, while Quartus II and Modelsim accept the second one, they
raise a parser error when trying to compile the first one.

I have found that Modelsim always wins
in battles with textbooks

If the "or" is changed with "and" the expression doesn't cause any
problems:

a and not b and not a and b

Those are all equal precedence operators
so left to right is ok.

-- Mike Treseler

 

[Fons]

              ^ Illegal
Have to finish the AND before
considering the lower precedence OR.

AND and OR have the same precedence according to the LRM, so this
cannot be the reason.

 

[Fons]

IINM, "and" and "or" operators are not allowed to be mixed without
parentheses in VHDL. This is from the heritage from ada.

Thanks, this makes sense. Is this incompatability reflected in the
grammar or is there a specific rule?

Furthermore, in what other cases are parenthesis required to separate
operators of equal reference? (i.e what other operators cannot be
mixed-up without parenthesis?)

My idea was to avoid printing parenthesis according to (parsing)
associativity, but from what I see I'll have to give up and only
remove parenthesis according to associativity.

Thanks,

Fons

 

[Fons]

operators of equal reference?

I meant "equal _precedence_", sorry

 

[Mike Treseler]

AND and OR have the same precedence

http://www.cs.umbc.edu/help/VHDL/operator.html

 

[Fons]

Brian and Mike,

And and or do not have the same precedence level. This ought to be in
the book somewhere.

http://www.cs.umbc.edu/help/VHDL/operator.html

This is confusing, I'm not following the book but the LRM, and it
states that or and and have the same precedence. VHDL93 LRM Section
7.2:



The operators that may be used in expressions are defined below. Each
operator belongs to a class of operators,
****all of which have the same precedence level***; the classes of
operators are listed in order of increasing
precedence.

logical_operator ::= and | or | nand | nor | xor | xnor
relational_operator ::= = | /= | < | <= | > | >=
shift_operator ::= sll | srl | sla | sra | rol | ror
adding_operator ::= + | – | &
sign ::= + | –
multiplying_operator ::= * | / | mod | rem
miscellaneous_operator ::= ** | abs | not

 

[Mike Treseler]

Parentheses are good, especially in machine-generated code,
and are completely free after the compiler has done its work.
They do a good job of sparing us from our own idiocy.

Some varieties of idiocy are immune to parentheses
Thanks for the fumble recovery.

-- Mike Treseler


“It ain't what you don't know that gets you into trouble.
It's what you know for sure that just ain't so.â€
Mark Twain

 

[Fons]

Yes, but LRM 7.1 (Expressions) gives the BNF for expressions,
and there you can clearly see that it is not possible to
combine more than one kind of logic operator in the same
expression unless you use parentheses, which can turn an
"expression" into a "primary".  

Thanks a lot! this makes it clear at last