RE: [sv-bc] confusion in determining the type of an self determined binary expression during evalution of type operator

Since all integral types are assignment compatible, it is indeed not
much important to let the conditional operator return the original
"common" matching type of the then- and else- expressions, when the type
is integral. The main reason for still doing that, in my eyes, is
consistency of the definition with non-integral types. If the definition
is different for integral and non-integral types, it will be more
complex to describe and understand it, not vice versa. But if others
think different, I will not insist, as both approaches will probably
work.

As for part selects, I assume that what you're asking is what is the
rationale for keeping the array bounds unnormalized, not what is the
rationale for keeping the shape of the type, as it is clear that the
shape should be kept, otherwise you couldn't even write a simple
assignment involving non-integral types:

logic a [3:1][2:1];
logic b [2:1][2:1];
assign b = a[2:1];

Regarding the normalization of the array bounds, it is important not to
normalize the bounds only if the language is extended to support selects
on arbitrary expressions (which I really hope will happen one day).
Consider the following code:

logic a [4:1][3:1];
logic b [3:1];
logic c;
assign b = a[3];
assign c = b[i];

A software tool (or even a human person) may decide to simplify the
above code by replacing the reference to "b" with the logic driving it
("a[3]"):

assign c = (a[3])[i];

The type of the expression in parenthesis should have the bounds [3:1],
not the normalized [2:0], otherwise the selection will not work as
expected. 

The other reason for keeping the type non-normalized is to let
expressions "(a[3])[i]" and "a[3][i]" be semantically equivalent, as
well as to avoid any ambiguity as to whether the "a[3][i]" syntax means
a single select with two selections, or two selects applied one on the
other. If the types are normalized, it will spark a lot of debates on
what should be the syntax for select operators and whether the
parenthesis is a purely syntactical creature or it also has effect on
semantics.

Answering the question from your next mail, the above are also the main
reasons for keeping the type shapes, as well as array bounds,
unnormalized even for integral types.

--Yulik.

-----Original Message-----
From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On
Behalf Of Steven Sharp
Sent: Tuesday, October 16, 2007 7:40 PM
To: sharp@cadence.com; Greg.Jaxon@synopsys.com; Feldman, Yulik
Cc: sv-bc@server.eda-stds.org; gordonv@model.com
Subject: RE: [sv-bc] confusion in determining the type of an self
determined binary expression during evalution of type operator


>From: "Feldman, Yulik" <yulik.feldman@intel.com>

>I would say that you need to normalize only if the types of then- and
>else- expressions do not match. If the types are matching (or "same"),
>it would be more useful to let the conditional operator return this
>type, rather than to artificially normalize it. This is especially true
>for non-integral types.

I agree for the non-integral types where strong type matching is
required.
Mantis 1594 and 1608 address the rules for classes.

For integral types, I don't see any reason to attempt this.  There are
already complex rules for determining the properties of the type in the
general case.  I don't see a reason to add more complexity with added
rules that only apply in a few special cases anyway.  Then users have
to know the extra rules, and the rules for when they apply.  What is
the use model that gets an advantage from adding this complexity?


>Aside conditional operators and identifiers, mentioned in this mail
>thread, other expressions that may (should be defined as able to) have
a
>type other than a simple scalar or a "normalized" one-dimensional
vector
>are part selects, cast operators, assignment operators, assignment
>patterns and maybe others.

I agree that the result type of a cast operator is clear.  The result of
an assignment operator is already specified to have the type of what it
was assigned to, so that is clear too.  An assignment pattern has a
clear
type, but I think that only matters for assignment compatibility, since
they cannot be used in any other contexts.  An assignment pattern
expression has a clear type.

I'm not convinced about part selects.  Can you provide any examples of
where it is even useful that they maintain the range?

Steven Sharp
sharp@cadence.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, 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.