RE: Fw: Version number macros

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

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