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

I agree that your proposal improves SV's correspondence with
state of the art C. I just think that C is behind the OO times
here, and feel that rather than further beat this horse,
we should investigate those C++ horseless carriages.

I also grew fond of (everything except the syntax of) the tagged
union proposal, and I'd personally like to see it move into
the mainstream of the SV language. But I don't yet have a comprehensive
proposal, and it wouldn't strictly speaking be an erratum. So
this isn't quite the forum, yet.

Since Doug's proposal appears to serve some particular needs
for unpacked unions, those would be programs that a switch to
tagged union layout would probably break. So I am kind of grieving
on that point. But languages evolve continuously, so if tagged unions
are worthwhile, they will overtake ordinary unions regardless of
the syntactic awkwardness. I can be patient.

Greg

Warmke, Doug wrote:
> > >
>
>>>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.
>>
>
>
> Greg,
>
> Interesting comments here!
>
> The main point of this proposal is to give unpacked unions a
> semantics as close as possible to C. I expect that the bulk of
> the use of these constructs will be done to model high level
> system aspects, bordering on pure software construction.
> If we stay consistent with C on the characteristics of
> unpacked unions, writing such SystemVerilog software will
> be a more natural and intuitive process. Reading between
> the lines of your comments, it seems like you would agree
> with this particular goal. (Though you have reservations
> about the use of unpacked unions in general, since in most
> cases there are better programming alternatives).
>
> Regards,
> Doug
>
>
Received on Wed Nov 17 15:59:25 2004