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(r) 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

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.