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

Greg,

> Disagreement seems to center on the partial casts - signedness mostly.
> When the committee confronted this disagreement they found 
> that $signed() implemented the most commonly sought 
> alternative to assignment-fidelity signed'().  This was why 
> the committee (at least in discussions) encouraged
> $signed() and signed'() to diverge - have it both ways!

I don't know whether or not that is correct. I was not involved in SV-BC
at the time, at least not deeply. I have not yet found documentation of
such a position by the committee. However, the current LRM definitely
does not specify that. The sentence, "When changing the signing, the
type of the expression to be cast shall pass
through unchanged, except for the signing," does not imply that the size
of the expression to be cast is extended according to its surroundings.
The sentence "The functions $itor, $rtoi, $bitstoreal, $realtobits,
$signed, and $unsigned can also be used to perform type conversions (see
Clause 19)," implies that signed() is the same as $signed. There is
certainly no implication that they are different.


>   So one alternative is to _not_call_it_casting_.  As 
> defined, signed'() acts primarily as a /barrier/ to the 
> upward propagation of unsigned type which otherwise poisons a 
> signed outer context.  This subtle effect is its only 
> defining characteristic, so calling it _signedness_firewall_ 
> would invite less confusion.

Well, that is the very question, what is the definition of signed'(). I
think it also shields the cast expression from size-extension to the
size of the external expressions, exactly as full type casting does.

>   A final alternative would be to make signed'() and 
> unsigned'() be exceptions to the rule that the operand of 
> cast is context-determined.

But in that rule, 'context' only refers to the cast type, not to the
other surrounding expressions. If "16'b0 + byte'(expr)" causes 'expr' to
be extended to 8 bits, not 16, why should "16'b0 + signed'(expr)" cause
'expr' to be extended to 16?

Regards,
Shalom
---------------------------------------------------------------------
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.