RE: enhancement/287: `compatibility - backward compatibilitycompilerdirectives

From: Stuart Sutherland (stuart@sutherland-hdl.com)
Date: Fri Jun 18 2004 - 13:00:00 PDT

  • Next message: Steven Sharp: "Re: enhancement/590: vector version of ?: operator"

    The following reply was made to PR enhancement/287; it has been noted by GNATS.

    From: "Stuart Sutherland" <stuart@sutherland-hdl.com>
    To: "'Steven Sharp'" <sharp@cadence.com>, <etf-bugs@boyd.com>
    Cc:
    Subject: RE: enhancement/287: `compatibility - backward compatibilitycompilerdirectives
    Date: Fri, 18 Jun 2004 12:51:24 -0700

     When I proposed enhancement 287, my primary concern was--and still
     is--keyword compatibility. What I would like to have is a standard way to
     specify that a tool *parse* older versions of the standard. I agree that it
     is not desirable to have tools be fully backward compatible for every
     feature and bug of previous standards.
     
     I suggest that the specification of the compatibility mode specifically
     state that the command only affects the reserved word list, and that the
     specification include the reserved words for 1364-1995 and for 1364-2001.
     That way no one has to go digging for obsolete LRMs to find the old reserved
     word lists.
     
     I have no strong preference as to how keyword backward compatibility is
     handled. The use of `compatibility, or even compiler directives in general,
     was meant as a suggestion to start the ball rolling. Perhaps it would be
     more clear if the directives were:
     
       `reserved_keywords 1955
       `reserved_keywords 2001
       `reserved_keywords 2005 (assuming a 1364-2005 standard)
       `reserved_keywords default (where default is the current 1364 standard)
     
     `resetall should be modified to state that it changes the `reserved_keywords
     directive to default.
     
     Regarding 1995 vs. 2001 compatibility, I recall there being three changes in
     2001 that were not backward compatible: new keywords, the extension of
     unsized literal X or Z values past 32 bits, and the reduction of $fopen from
     31 MCDs to 30 MCDs.
     
     Stu
     ~~~~~~~~~~~~~~~~~~~~~~~~~
     Stuart Sutherland
     stuart@sutherland-hdl.com
     503-692-0898
     
    > -----Original Message-----
    > From: owner-etf@boyd.com [mailto:owner-etf@boyd.com] On
    > Behalf Of Steven Sharp
    > Sent: Friday, June 18, 2004 11:10 AM
    > To: etf-bugs@boyd.com
    > Subject: Re: enhancement/287: `compatibility - backward
    > compatibilitycompilerdirectives
    >
    > The following reply was made to PR enhancement/287; it has
    > been noted by GNATS.
    >
    > From: Steven Sharp <sharp@cadence.com>
    > To: etf-bugs@boyd.com, Shalom.Bresticker@freescale.com
    > Cc:
    > Subject: Re: enhancement/287: `compatibility - backward
    > compatibilitycompilerdirectives
    > Date: Fri, 18 Jun 2004 14:10:18 -0400 (EDT)
    >
    > > However, if "1364-2001 compatibility" would require
    > > him to disable any and all features added in later versions of the
    > > standard, that would be much harder for a vendor to implement,
    >
    > In fact, if the earlier versions of the standard are not readily
    > available, this is a bigger issue than just implementation effort.
    >
    > I believe that if this directive is added to the standard, that the
    > behavior required to be compliant needs to be fully specified in the
    > standard also. I don't believe that referring to an earlier
    > obsoleted
    > version of the standard is a valid specification.
    >
    > Trying to specify everything that has changed from all
    > previous versions
    > of the standard is impractical. Restricting it to something smaller,
    > such as just keywords, or just the things that are not
    > backward-compatible,
    > would make both specification and implementation much simpler.
    >
    >
    > > It is true that there are a few things which actually
    > change from one
    > > version of the standard to the next, as opposed to added
    > extensions,
    > > such as the use of bit 31 of an MCD, but those cases have
    > been quite few
    > > and relatively unimportant.
    >
    > The change in x/z-extension behavior for unsized literals is
    > the only other
    > one I can think of.
    >
    > Steven Sharp
    > sharp@cadence.com
    >
    >
    >
    >
     

    This archive was generated by hypermail 2.1.4 : Fri Jun 18 2004 - 13:00:08 PDT and
    sponsored by Boyd Technology, Inc.