RE: [sv-ac] Re: [sv-bc] Re: if-else

I already checked our implementation, and it agrees with my
interpretation, independently by the way. (At least someone did)

The rules you quoted are now in 11.7.2 and I would say they are weak
because by that step, the signedness has already been determined. It
also conflict's with what's in 11.4.5. I interpret the rules in 11.4.5
to apply to any expression and not a simplification that only applies to
simple operands.

But let's get agreement on what the behavior SHOULD be and then argue
what should be written in the LRM. I think each side should be evaluated
in a self-determined context and then the rules in 11.4.5 should apply.

> -----Original Message-----
> From: Steven Sharp [mailto:sharp@cadence.com]
> Sent: Thursday, November 01, 2007 6:20 PM
> To: sharp@cadence.com; Rich, Dave
> Cc: sv-ac@eda.org; sv-bc@eda.org
> Subject: RE: [sv-ac] Re: [sv-bc] Re: if-else
> 
> 
> >You seem to have a different interpretation of what a correct
> >implementation should be. :)
> >
> >I think you are incorrectly determining that the result of the
> >arithmetic shift should be unsigned. That would be true in the case
of
> >an arithmetic or relational operation, but not in the case of
equality.
> >Equality has its own explicit rules for dealing with signedness.
> 
> I re-checked the 1364-2005 standard, and we actually put in a pretty
> good description of the full rules for the relational and equality
> operators.  In 5.5.2 it says
> 
> "However, there are two exceptions:
> 
>   -- The relational and equality operators have operands that are
neither
>      fully self-determined nor fully context-determined.  The operands
>      shall affect each other as if they were context-determined
operands
>      with a result type and size (maximum of the two operand size)
> determined
>      from them.  However, the actual result type shall always be 1 bit
>      unsigned.  The type and size of the operand shall be independent
of
>      the rest of the expression and vice versa."
> 
> So if you have a signed and unsigned operand, they affect each other
as
> if they were context-determined operands with an unsigned result type.
> That means that the unsignedness gets propagated down into them by the
> usual rules for context-determined operands.  The results that I
described
> then follow.
> 
> You might want to test your own implementation on this...
> 
> Steven Sharp
> sharp@cadence.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.