Re: [sv-bc] E-mail Vote: Closes 12am PST Nov 17

Maidment, Matthew R wrote:
> Hello Everyone.
>
> It's time for another email vote. Please remember that the
> operating guidelines specify:

> Greg Jaxson

Drop the "s". Jaxon rhymnes with saxon.

>
> 272 ___Yes ___No ABSTAIN
> http://www.eda.org/svdb/bug_view_page.php?bug_id=0000272
>
> 273 ___Yes ___No ABSTAIN with comment
> http://www.eda.org/svdb/bug_view_page.php?bug_id=0000273

I had trouble reading the html of Doug's proposal, so my
criticism may be misplaced. In the case of C unions, I
believe that "safe" accesses via cooperating members was
added to support implementation of C++ class inheritance.
I don't see this as a long term (or even short term) need
of SV, considering that we have an SV class system as
part of the current language design. There are also several
other approaches - albeit more intrusive - to implementing
derived class hierarchies using unpacked structs and unions.
The advantage of intruding into the cooperating struct
layouts is that the owners of the layouts are forced to
acknowledge explicit cooperation, and therefore breakdowns
(which are essentially impossible to detect) will be less
likely to happen in practice.

On the contrary, I see unpacked unions as the proper syntactic
home for the feature currently documented as "tagged" unions.
When a class-like hierarchy is built explicitly using tagged
unions, one gets full runtime type-checking. Short of being
able to synthesize virtual function calls, I know of no other
way to safely access a base class.

So my objection is not so much to Doug's revision of
current unpacked unions. Rather I object to the current
definition of unpacked unions as too unreliable for
everyday use. I want to resist the urge to patch a bad
situation.

However, being new to this community, I don't intend to
get obstructionist about it. Rather than vote NO, I will
abstain.

> 276 _X_Yes ___No
> http://www.eda.org/svdb/bug_view_page.php?bug_id=0000276
>
> 285 _X_Yes ___No
> http://www.eda.org/svdb/bug_view_page.php?bug_id=0000285
>
> 291 ___Yes ___No (ABSTAIN, YES if a friendly amendment is accepted)
> http://www.eda.org/svdb/bug_view_page.php?bug_id=0000291

Please drop the sentence.

"An explicit cast between packed types is not required since
they are implicitly cast as integral values, but a cast can
be used by tools to perform stronger type checking."

I don't understand how explicit casts can be used to perform
stronger type checking. At best they may be used to suppress
warnings from LINT-like tools. Adding them to code actually
threatens type-safety, since unpacked casts ARE unsafe and
conceal mismatched packedness.

Furthermore, there are times when explicit casts of packed
types are intended to control the choice of sign or zero extension.
I'd rather have those stand out than be lost in a sea of
lint-appeasing redundancy.

Since this sentence is not normative, I suggest dropping it
altogether. This also removes a use of the term "implicit cast"
which I find misleading.

---- Aside -----
I think a paragraph warning about the peculiar differences between
implicit casts in C and in Verilog and between implicit casts
done on assignment, and those done inside Verilog expressions
would be much more helpful.
----------------

>
> The issues below are related to 254. Brad has annotated
> the Bug Notes section of each of these issues with relevant
> information.
>
> PROPOSED DUPLICATES oF 254 BASED ON RESOLUTION OF 254:

> 014 _X_Yes ___No Issue is now resolved, duplicate of 254, based on
> resolution of 254.
> http://www.eda.org/svdb/bug_view_page.php?bug_id=0000014
>
> 032 _X_Yes ___No Issue is now resolved, duplicate of 254, based on
> resolution of 254.
> http://www.eda.org/svdb/bug_view_page.php?bug_id=0000032
>
> 094 _X_Yes ___No Issue is now resolved, duplicate of 254, based on
> resolution of 254.
> http://www.eda.org/svdb/bug_view_page.php?bug_id=0000094
>
> 100 _X_Yes ___No Issue is now resolved, duplicate of 254, based on
> resolution of 254.
> http://www.eda.org/svdb/bug_view_page.php?bug_id=0000100
>
> 146 _X_Yes ___No IIssue is now resolved, duplicate of 254, based on
> resolution of 254.
> http://www.eda.org/svdb/bug_view_page.php?bug_id=0000146
>
> 212 _X_Yes ___No Issue is now resolved, duplicate of 254, based on
> resolution of 254.
> http://www.eda.org/svdb/bug_view_page.php?bug_id=0000212

>
> PROPOSED NOT A BUG BASED ON RESOLUTION OF 254:
> 102 _X_Yes ___No Issue is no longer a bug, based on resolution of
> 254.
> http://www.eda.org/svdb/bug_view_page.php?bug_id=0000102

Thanks,
Greg Jaxon
Received on Mon Nov 15 11:49:01 2004