Subject: RE: [vhdl-200x] Implicit conversion, Overloading, & Strong Typin g
From: Bailey, Stephen (SBailey@model.com)
Date: Thu Dec 18 2003 - 22:36:16 PST
Hamish,
> Jim Lewis wrote:
> > Actually, I believe you are comfortable with this
> > behavior, you are just stuck on "implicit".
> > Let me give an example:
> >
> > signal A, Y : unsigned (8 downto 0) ;
> >
> > Y <= A + "000001111" ;
> > vs.
> > Y <= A + 15 ;
> >
> > This is overloading. The compiler picks the right "+" operator
> > to call based on the equation and we are happy. It only knows
> > which one to call based on type of the operands.
> >
> >
> > Likewise:
> > if Cs = '1' and Cs2 = '1' then -- if1
> > vs.
> > if Cs1 and Cs2 then -- if2
> >
> > Here the compiler also picks the right "COND" operator for the
> > expression. For the first one (if1), it sees the top
> > expression is boolean so it realizes it does not need to
> call "COND".
>
> In the first example, you specifically called "+" and expected the
> compiler to find the right one. In the second example you
> called AND it
> find the right one too. That's fine and quite logical.
>
> But you didn't explicitly called "COND" at all. That's
> foreign to VHDL.
The point Jim was trying to make is that you are calling COND because the condition context requires a boolean value and a COND that matches is visible. Remember that VHDL's syntax defines the following contexts (and only these contexts) that *condition* can occur (this is documented in the proposal):
- assert *condition* ...
- if *condition* (if statement and if-generate)
- elsif *condition*
- wait [...] until *condition* [...]
- when *condition* ... (conditional signal assignment, exit, next)
- while *condition*
- to be defined PSL expressions
We actually discussed an alternative way to arrive at the same functionality. Since people seem to be hung up on this implicit call and cannot make the connection to how it is just a tiny extension to operator overloading capabilities already in the language:
- What if assert, if, elsif, until, when and while were defined in the language as operators.
- Users could then overload the operators to take a parameter of any type and return boolean.
- Tools would apply subprogram overload resolution just as they do today to select which visible if, etc. operator to apply.
This would work exactly like today's subprogram overloading capabilities. We thought the COND proposal would be easier to digest and accept. We may have been wrong in that regard as the if, etc. as operators proposal should not lead to people misinterpreting the proposal as Hamish (and others) have done by trying to apply it to contexts in which it isn't allowed (see next comment).
(Note: The idea of if, etc. being overloaded operators would not impact how branching, etc. work. Only how the expression is interpreted as TRUE/FALSE.)
> By the way, does the implicit "COND" call only apply to if?
> What about
> assignments to boolean, as in
>
> signal z: boolean;
> signal x, y: bit;
>
> begin
> z <= x and y;
> end if;
>
> Logically this should work too, if it works with if.
No, it does not logically work because this is NOT a condition context. There is no explicit context (nothing in the syntax that indicates that the LHS is boolean) which makes it obvious that the result of the RHS should be converted to boolean.
We did not want the proposal to apply to this situation and it does not.
-Steve Bailey
This archive was generated by hypermail 2b28 : Thu Dec 18 2003 - 22:40:02 PST