From: Steven Sharp (sharp@cadence.com)
Date: Fri Jun 18 2004 - 11:10:01 PDT
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 - 11:10:07 PDT
and
sponsored by Boyd Technology, Inc.