RE: [sv-bc] sign/width casting semantics

I have to put my two cents to this interesting discussion.

 

First of all, the LRM is indeed unclear on this point, and this is the
reason this issue is raised over and over again. I think I agree with
most arguments raised in the mail thread until now, Shalom's and Greg's
and others ;)

 

With regard to the effect the signed'() has, I think nobody argues that
signed'() forces the type to signed while propagating the type context
in upward direction. The main point of confusion, as I see it, is
whether the signedness context is propagated from signed'() to its
operand in downward direction. If it is, then, if the context is signed,
and remains signed when it reaches the "leaf" operands of the
expression, these operands should be sign-extended. In all other cases,
they should be zero-extended. 11.7.2 is explicit about that: "If the
operand must be extended, then it shall be sign-extended only if the
propagated type is signed".

 

So, is signedness context propagated from result of signed'() to its
operand? 

 

The question of whether the operand of signed'() is (or should be)
self-determined or context-determined is a part of this bigger question.
For $signed() (as opposed to signed'()), the answer is quite clear,
since $signed() is a function call and thus the type of its arguments is
not affected by the function call context. Therefore, the signedness is
not passed down. For signed'(), the answer is not clear, for several
reasons:

 

1. 6.24.1 says "When changing the signing, the type of the expression to
be cast shall pass through unchanged, except for the signing", but it
doesn't elaborate which direction of the "pass" is affected, the upward,
the downward, or both. It also doesn't make it clear what it means to
"pass signing in a 'non unchanged form'". For upward direction, it most
probably means forcing the signing for the result of the signed'().
However, for downward direction, it may mean either forcing the signing
for the underlying expression or avoiding propagating the signedness
context from above. The third option could be to pass signedness context
from above as is, in case the sentence is meant to apply to upward
propagation only.

 

2. 6.24.1 also says "The cast shall return the value that a variable of
the casting type would hold after being assigned the expression" and we
know from 11.7.3 that signedness of LHS of assignment doesn't affect the
RHS. If the 6.24.1 excerpt from the first bullet is meant to affect the
downward propagation direction too, then to avoid a conflict with the
said here, the meaning of 'non unchanged form' should be avoiding
propagating the signedness context from above (in line with Greg's
opinion).

 

3. It is not clear whether the operand of cast operator should be
considered context-determined or self-determined. The Table 11-23 in
11.6.1 was not updated with SV operators yet. I'm also not sure SV-BC's
Issue 38 mentioned by Greg is indeed a good reason to treat the operand
as context-determined, as this portion of the standard was subsequently
overridden by 6.24.3 "Bit-stream casting" (as I understand), which
doesn't mention the self vs. context determination, leaving the question
open again.

 

4. It is not clear whether the cast operator itself should be considered
a "simple operand" or not. Section 11.5 doesn't list it as an operand
explicitly. However, the cast operator is a "primary" in BNF. This makes
the 11.7.2's "When propagation reaches a simple operand as defined in
11.5 (a primary as defined in A.8.4), ..." very confusing. BTW, it would
be very nice to rename the 11.5's "operand" term to something like
"simple operand" to void ambiguity in the term itself, since it is used
in both its meanings throughout 11.7. 

 

All of the above contribute to the confusion about this issue. To make
the definition unambiguous, I think at least the following needs to be
unambiguously defined:

 

1. How signedness is propagated from the context of signed'() to its
operand? To recall, there are three options: a) it is propagated as is,
b) a signed context is forced and c) signedness is self-determined.

 

2. How the size is propagated from the context of signed'() to its
operand, if at all? Is the operand self-determined or
context-determined?

 

Once these questions are answered, one could unambiguously decide
whether to apply sign or zero extension to the simple operands inside
signed'() and to what size to extend them.

 

I myself don't have a special preference to how it should be defined,
but I agree with Brad and Shalom, that defining signed'() as having the
same effect as $signed() (and same for unsigned'()/$unsigned(), of
course) is a good idea as it would be easy to remember and understand.
Defining the two as having different behavior (like if signed'()'s
operand's size is context-determined) also has positive sides, but I'm
not sure how the added value would compare against having different
definitions for the two.

 

--Yulik.

 

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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