Re: [sv-bc] RE: Mantis 1523 conditional operator with arrays

I agree with Steven here -- the type must be invariant for any situation
including "elaboration optimization" for constant expression conditions.
If an implementation is "optimizing" to a non-real type, that is an error.

Gord.

On 9/20/2011 6:26 PM, Steven Sharp wrote:
>
> It doesn't matter whether the evaluation is done at elaboration time
> or runtime. The data type of an expression is not dependent on the
> values of the operands, only their type. If some tool is changing the
> data type based on evaluation at elaboration time as an "elaboration
> time optimization", then that tool is wrong. You should report it as
> a bug.
>
> The type of the expression should be real, regardless of the value of
> the condition. Dave brought up the fact that the second bullet was
> wrong because a real value can be implicitly cast to an integral
> expression (though only in an assignment, not during evaluation of an
> expression, which is the form of implicit casting that was probably
> meant by the author), yet the result in that case should be real. I
> thought that he had corrected that by explicitly calling out that case
> in his proposal.
>
> *From:*Bresticker, Shalom [mailto:shalom.bresticker@intel.com]
> *Sent:* Tuesday, September 20, 2011 7:34 AM
> *To:* Steven Sharp; sv-bc@eda.org
> *Subject:* RE: Mantis 1523 conditional operator with arrays
>
> Hi,
>
> I looked into this more. As you and Greg have hinted, the key words
> here are "static" and "runtime".
>
> I found the following, testing on the two simulators I currently have
> access to.
>
> One expression is integral and the other is real.
>
> Where the cond_predicate can be determined only at runtime (i.e., a
> non-constant expression), the result is real. This seems to in any
> case be different from the LRM requirement:
>
> The conditional operator can be used with nonintegral types (see
> 6.11.1) and aggregate expressions (see 11.2.2) using the following rules:
>
> --- If both the first /expression /and second /expression /are of
> integral types, the operation proceeds as defined.
>
> --- If the first /expression /or second /expression /is an integral
> type and the opposing expression can be implicitly cast to an integral
> type, the cast is made and proceeds as defined.
>
> The last sentence quoted indicates that the result type should be
> integral, but it is not.
>
> Where the cond_predicate is constant, and therefore its value can be
> evaluated at elaboration time, if the integral value is selected by
> the cond_predicate, one of the simulators indeed treats it the same
> way as in runtime, as cast to real. However, the other simulator
> treats the result as being of integral type, apparently the result of
> an elaboration time optimization.
>
> As noted, neither behavior conforms to the current nor the proposed
> LRM text.
>
> Regards,
>
> Shalom
>
> *From:*Steven Sharp [mailto:sharp@cadence.com]
> *Sent:* Tuesday, September 20, 2011 3:59 AM
> *To:* Bresticker, Shalom; sv-bc@eda.org
> *Subject:* RE: Mantis 1523 conditional operator with arrays
>
> Shalom, when you say that the result is either integral with the
> integral value or real with the real value, are you talking about the
> case where one expression is integral and the other is real? If so, I
> am interested in how you tested this, because what you are saying
> makes no sense. The type of an expression is determined statically,
> and does not depend on the values of the operands at runtime.
>
> *From:*owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] *On Behalf Of
> *Bresticker, Shalom
> *Sent:* Monday, September 19, 2011 6:05 AM
> *To:* sv-bc@eda.org
> *Subject:* [sv-bc] RE: Mantis 1523 conditional operator with arrays
>
> Hi,
>
> I was away for a few days.
>
> I don't think the wording is satisfactory.
>
> It says,
>
> "For integral expressions, if the /cond_predicate /evaluates to an
> ambiguous value and the /expressions /are not logically equivalent,
> their results shall be combined bit by bit using Table 11-20 to
> calculate the final result unless either the first or second
> expression is real, in which case the result shall be 0."
>
> The phrases "integral expressions" and "either the first or second
> expression is real" are contradictory. No mention there of casting.
> The mention of casting is later. The wording does not even say that if
> one expression is integral and the other is real, that casting does
> not occur.
>
> In fact, according to my experiments, where the cond_predicate is true
> or false, not ambiguous, the result is either the integral value with
> integral type, or the real value with real type. (No casting at all!)
> The text certainly does not describe that.
>
> The text that appears later,
>
> "If the first /expression /or second /expression /is an integral type
> and the opposing expression can be implicitly cast to an integral
> type, the cast is made and proceeds as defined,"
>
> also makes no exception for the case that one expression is integral
> and the other is real.
>
> I realize you say that the proposal does not address that part of the
> text, but it adds the phrase "For integral expressions" at the
> beginning and makes the situation worse, in my opinion.
>
> It will be difficult for me to vote in favor of this proposal at the
> Champions level.
>
> Regards,
>
> Shalom
>
> *From:*Rich, Dave [mailto:Dave_Rich@mentor.com]
> *Sent:* Tuesday, September 13, 2011 8:40 AM
> *To:* Bresticker, Shalom; Maidment, Matthew R; sv-bc@eda.org
> *Subject:* RE: Mantis 1523 conditional operator with arrays
>
> Shalom,
>
> It was because of that complication that both expressions become
> integral -- a real would be cast to an integral, which is the reverse
> of what happens when you mix reals and integrals with other operators.
> So the exception for reals must be left in place. Not ideal wording,
> but that's not what this proposal is addresses.
>
> Dave
>
> *From:*Bresticker, Shalom [mailto:shalom.bresticker@intel.com]
> *Sent:* Monday, September 12, 2011 7:35 PM
> *To:* Maidment, Matthew R; Rich, Dave; sv-bc@eda.org
> *Subject:* RE: Mantis 1523 conditional operator with arrays
>
> The phrase "For integral expressions" is new, added in this proposal.
> To me, since it is plural, it means that both expressions are integral.
>
> It really sounds strange: "For integral expressions ... unless either
> ... expression is real".
>
> There is also the complication that the following text says:
>
> The conditional operator can be used with nonintegral types (see
> 6.11.1) and aggregate expressions (see 11.2.2) using the following rules:
>
> --- If both the first /expression /and second /expression /are of
> integral types, the operation proceeds as defined.
>
> --- If the first /expression /or second /expression /is an integral
> type and the opposing expression can be implicitly cast to an integral
> type, the cast is made and proceeds as defined.
>
> That would give a different result.
>
> Regards,
>
> Shalom
>
> *From:*Maidment, Matthew R
> *Sent:* Tuesday, September 13, 2011 2:30 AM
> *To:* Bresticker, Shalom; Rich, Dave; sv-bc@eda.org <mailto:sv-bc@eda.org>
> *Subject:* RE: Mantis 1523 conditional operator with arrays
>
> Hi Shalom.
>
> For the first issue, the proposal was modified as follows:
>
> Regardless of the result of the /cond_predicate/,the first and second
> expressions are extended to the same width, as described in 11.6.1 and
> 11.8.2.
>
> For the second issue the phrasing is:
>
> For integral expressions, if the /cond_predicate /evaluates to an
> ambiguous value and the /expressions /are not logically equivalent,
> and their results shall be combined bit by bit using Table 11-20 to
> calculate the final result unless either the first or second
> expression is real, in which case the result shall be 0.
>
> And that seems to make sense---it's covering the case when there is
> one integral and one real expression. What's the problem?
>
> Matt
>
> *From:*owner-sv-bc@eda.org <mailto:owner-sv-bc@eda.org>
> [mailto:owner-sv-bc@eda.org] <mailto:[mailto:owner-sv-bc@eda.org]> *On
> Behalf Of *Bresticker, Shalom
> *Sent:* Monday, September 12, 2011 5:41 AM
> *To:* Rich, Dave; sv-bc@eda.org <mailto:sv-bc@eda.org>
> *Subject:* [sv-bc] RE: Mantis 1523 conditional operator with arrays
>
> Hi,
>
> In the current LRM, the sentence that says for integral operands, "the
> first and second expressions are extended to the same width" is not
> dependent on the value of cond_predicate. As you have reformulated it,
> that sentence applies only when cond_predicate is ambiguous and the
> expressions are not logically equivalent.
>
> Also, by adding "For integral expressions," then the phrase "unless
> either the first or second expression is real, in which case the
> result shall be 0," should be deleted.
>
> Regards,
>
> Shalom
>
> *From:*owner-sv-bc@eda.org <mailto:owner-sv-bc@eda.org>
> [mailto:owner-sv-bc@eda.org] <mailto:[mailto:owner-sv-bc@eda.org]> *On
> Behalf Of *Rich, Dave
> *Sent:* Saturday, September 10, 2011 9:47 AM
> *To:* sv-bc@eda.org <mailto:sv-bc@eda.org>
> *Subject:* [sv-bc] Mantis 1523 conditional operator with arrays
>
> New proposal based on feedback from Aug 29^th meeting uploaded.
>
> http://www.eda.org/svdb/view.php?id=1523
>
> ---------------------------------------------------------------------
> 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* <http://www.mailscanner.info/>, and is
> believed to be clean.
>
> ---------------------------------------------------------------------
> 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* <http://www.mailscanner.info/>, and is
> believed to be clean.

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.