[sv-bc] 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.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.