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

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 29th 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, and is
believed to be clean.