VHDL Operator associativity (Quartus II parser bug?)

F

Fons

Guest
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.
 
Fons wrote:

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
Click to expand...
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.
Click to expand...
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
Click to expand...
Those are all equal precedence operators
so left to right is ok.

-- Mike Treseler
 
On Jun 18, 5:20 pm, Fons <alfonso.aco...@gmail.com> wrote:
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.
Click to expand...
IINM, "and" and "or" operators are not allowed to be mixed without
parentheses in VHDL. This is from the heritage from ada.

Andy
 
On 18 jun, 19:23, Mike Treseler <mike_trese...@comcast.net> wrote:
Fons wrote:
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.
Click to expand...
AND and OR have the same precedence according to the LRM, so this
cannot be the reason.
 
On 18 jun, 19:00, Andy <jonesa...@comcast.net> wrote:
IINM, "and" and "or" operators are not allowed to be mixed without
parentheses in VHDL. This is from the heritage from ada.
Click to expand...
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
 
On Wed, 18 Jun 2008 15:20:56 -0700 (PDT), Fons
<alfonso.acosta@gmail.com> wrote:

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."

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.
Click to expand...
And and or do not have the same precedence level. This ought to be in
the book somewhere.

- Brian
 
On Thu, 19 Jun 2008 09:23:18 -0700 (PDT), Fons wrote:

This is confusing, I'm not following the book but the LRM, and it
states that or and and have the same precedence.
Click to expand...
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". The same BNF also ingeniously
prohibits the use of more than one "nand" or "nor" operator
in an expression without parentheses, while allowing such
things as
a and b and c

So the folk who told you that "and" and "or" have different
precedence are indeed wrong, but it doesn't matter a scrap
because you can never use them together in an un-parenthesised
expression.

Why, by the way, are you so keen to strip unwanted parentheses?
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.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
Jonathan Bromley wrote:

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.
Click to expand...
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
 
Brian and Mike,

On 19 jun, 09:37, Brian Drummond <brian_drumm...@btconnect.com> wrote:
And and or do not have the same precedence level. This ought to be in
the book somewhere.
Click to expand...
On 19 jun, 11:31, Mike Treseler <mike_trese...@comcast.net> wrote:
http://www.cs.umbc.edu/help/VHDL/operator.html
Click to expand...
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
 
On Thu, 19 Jun 2008 17:39:35 +0100, Jonathan Bromley
<jonathan.bromley@MYCOMPANY.com> wrote:

On Thu, 19 Jun 2008 09:23:18 -0700 (PDT), Fons wrote:

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

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".
Click to expand...
Interesting; learned something new!
Thanks to both of you,

- Brian
 
On 19 jun, 12:39, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
On Thu, 19 Jun 2008 09:23:18 -0700 (PDT), Fons wrote:
This is confusing, I'm not following the book but the LRM, and it
states that or and and have the same precedence.

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".  
Click to expand...
Thanks a lot! this makes it clear at last
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top