Re: Fw: Version number macros

+1 from my side.
P.

On 07/10/10 18:45, john.aynsley@doulos.com wrote:
> Jerome,
>
> I am fine with having a macro IEEE_1666_SYSTEMC with a value that is
> hardcoded in the IEEE 1666-2011 standard (e.g. 201101L) together with a
> statement in the standard that says it is the intent that future versions
> of the standard will replace this macro with a numerically greater value.
>
> I don't think the TLM version macros are useless at all: I think the most
> likely chain of events is that OSCI will make a point release of TLM-2.0
> before the next IEEE re-standardization (5 years from now) and that
> one-by-one EDA vendors will gradually adopt the latest OSCI release with
> at most minor alterations. The TLM version macros can then be used by
> applications to detect the version, long before the enhancements find
> there way into the IEEE. Whatever, since we all agree the TLM version
> macros are necessary for compatibility, we have nothing left to argue
> about 8=)
>
> I disagree with your assumption that the version number of the IEEE
> standard will have much practical impact. I can't think of many EDA tools
> that offers 100% support for any IEEE standard, and SystemC is no
> exception. Vendors always have subsets, enhancements, and bugs. Even the
> OSCI PoC standard does not support dynamic processes or fixed point types
> unless you remember to turn them on, and it never has implemented
> sc_signal correctly out-of-the-box, yet presumably we would want it to
> define IEEE_1666_SYSTEMC? But again, I don't think we have anything left
> to argue about.
>
> I propose we add IEEE_1666_SYSTEMC as defined above together with a full
> set of SC and TLM-2.0 macros/functions, modified with extern const and
> removing inline as proposed by Philipp.
>
> Are we done?
>
> Cheers,
>
> John A
>
>
>
> From:
> Jerome CORNET <jerome.cornet@st.com>
> To:
> "john.aynsley@doulos.com" <john.aynsley@doulos.com>,
> "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
> Date:
> 07/10/2010 15:57
> Subject:
> RE: Fw: Version number macros
>
>
>
> John,
>
> comments below.
>
> From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
> Sent: Thursday, October 07, 2010 12:47 PM
> To: Jerome CORNET; systemc-p1666-technical@eda.org
> Subject: RE: Fw: Version number macros
>
> All,
>
> I am okay with adding a macro to 1666 which indicates which version of the
> standard an implementation is nominally intended to support. But I would
> like to spell out a few things, just to be sure we are all on the same
> page. My apologies if this was all obvious to you anyway 8=)
>
> * I would prefer the name IEEE_1666_SYSTEMC, but only because that has the
> same rhythm as the actual title of the standard (IEEE Standard SystemC®
> Language Reference Manual)
> No problem with that.
>
> * The IEEE standard is set in concrete for a few years. The standard can
> try to anticipate the future, but cannot specify version numbers for
> future patches, branches etc. So, exactly what do we mean by defining a
> standard symbol with a standard value like 201001L? Who is going to
> control the succession of values (201002L and so forth). It would make
> sense to me that each IEEE standard specifies a value that identifies
> itself and itself alone (e.g. 2011L), rather than trying to allow for
> future increments. Say the IEEE releases a Clarification document
> alongside 1666-2011 in a few years time. That clarification document would
> specify its own value, e.g IEEE_1666_SYSTEMC 2013L (with some appropriate
> constraints on the data type). But perhaps this is just what you intended
> all along? In which case 201001L (or whatever we finally choose) is fine,
> though I might prefer yyyymmL
> I have taken a look again at the C++ standard. Indeed it is (mostly) on
> the same line as you. They basically say ?__cplusplus? is defined the
> following value xxxxxxx (which is hardcoded). There is
> however a note that says: It is intended that future versions of this
> standard will replace the value of this macro with a greater value. (which
> is enough wording for the macro to be useful; i.e.
> it can be tested with a < or > operator).
> Now, I am not sure to understand what you prefer. To clarify my opinion:
> if we release in 2011 a clarification document,
> and that the implementation wants to indicate that it obeys the
> clarification, I would choose 201002L as the macro value. That would
> means: this is ?revision? 2 of the IEEE 1666-2010 norm.
> The 2 or whatever is up to us. In the case of C++, they start their mm at
> 11 (probably because they made 10 attempts before?). But I would change
> the ?year? part only every 5 years (at each big norm revision).
>
> * The presence of this macro does NOT guarantee compliance to any standard
> or to any version of any standard. It is just an indication of intent.
> "This implementation is supposed to support IEEE standard version
> such-and-such". That's another reason I don't see any point in making it
> fine-grained. It should just be enough to identify a specific version of a
> specific IEEE standard (and they don't change that often)
>
> I am not really convinced by that argument (and your next point seems
> contradictory with it btw). Anyway we are not writing a lawyer?s document
> ;-)
> I was just questioning what effective use can be done of the existing
> TLM_xxxx_VERSION macros in the TLM part (and the only answers I have got
> revolve around ?this is pretty
> much useless as is?). That said, I prefer keeping / enhancing them and
> preserve backward compatibility.
>
> * The OSCI PoC implementations (SystemC and TLM-2.0) have a special
> status, because OSCI is the "custodian" of SystemC standardization. When
> OSCI release an updated standard (without necessarily submitting this to
> the IEEE) then OSCI will increment the version numbers appropriately. Most
> software vendors would wish to indicate that their products are compatible
> with certain versions of the OSCI PoC implementations (as well as with
> certain IEEE standards), so would choose appropriate version numbers
> (perhaps using the same MAJOR and MINOR numbers but adding their own
> ORIGINATOR and PATCH). That is their call. We could make stronger
> recommendations in P1666 though? The point I'm making is that vendors will
> probably have good commercial reasons for basing their product versions on
> OSCI PoC versions as well as making a claim to support an IEEE standard.
> They are unlikely to want to generate SystemC or TLM-2 versions unrelated
> to the OSCI PoC.
> I am not sure this way of thinking is not counter-productive with respect
> to the IEEE norm. We want (at least I) the norm to be the reference in
> terms of features that can be used or not.
> The prefered way of testing, say the availability of process control
> extension would be to look for the 2010 version number of the norm,
> instead of saying that version 2.3.x of the OSCI PoC implements it
> , everyone is based on it, therefore that the SYSTEM_VERSION macros can be
> used.
> However, I see the SystemC version macros as useful to test for a
> particular SystemC implementation, to say implement a workaround or
> benefit for a particular feature that is not in the norm.
>
> Regards,
> Jerome
>
>
>
>
>

-- 
Philipp A. Hartmann
Hardware/Software Design Methodology Group
OFFIS Institute for Information Technology
R&D Division Transportation · FuE-Bereich Verkehr
Escherweg 2 · 26121 Oldenburg · Germany
Phone/Fax: +49-441-9722-420/282 · PGP: 0x9161A5C0 · http://www.offis.de/
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.