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)

* 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

* 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)

* 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.

Opinions?

John A
 

From:
Jerome CORNET <jerome.cornet@st.com>
To:
"Philipp A. Hartmann" <philipp.hartmann@offis.de>,
"john.aynsley@doulos.com" <john.aynsley@doulos.com>
Cc:
"systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
Date:
05/10/2010 14:20
Subject:
RE: Fw: Version number macros

Agreed with Philipp on all points.

Some remarks though:

1) as we are reexamining the API, it was worth asking ourselves in which
way the TLM macros can be used. In my opinion, if vendor X's
implementation returns TLM_VERSION_MAJOR as 1.0 for a TLM-2
compliant implementation, and vendor Y's chooses to return 2 as the OSCI
implementation (which would seem
to me "more" logical), I don't see in which way the macro will indeed by
useful to anyone. This is different
from SystemC's version macros which allows to test a particular version
for a particular vendor.

2) it is essential (as Philipp pointed out below) to define a macro
indicating which version of the standard
the implementation does follow (which was the starting point of this
discussion). If we have got this one,
we have at least a way to pin down indirectly and roughly which "TLM" kit
"version" (1.0 or 1.0+2.0 or a later revision)
is actually available (and can forget point 1) if it really opens a can of
worms...)

As John said, we are in a hurry, not for leaving things as they were (that
is without any macro to test IEEE revision
and without any changes requested on this list, which would not be very
beneficial to the norm), but rather for getting other
participants' opinion on this topic.

Cheers,

Jerome

-----Original Message-----
From: owner-systemc-p1666-technical@eda.org [
mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of Philipp A.
Hartmann
Sent: Tuesday, October 05, 2010 2:56 PM
To: john.aynsley@doulos.com
Cc: systemc-p1666-technical@eda.org
Subject: Re: Fw: Version number macros

John,

I agree, that we should try to keep backwards compatibility here, as
much as possible. Wrt. to the set of constants/defines for SystemC,
I've stated my preferences earlier, but I'm fine with whatever decision,
the group takes.

Wrt. the values, returned from these constants: Yes, they should stay
implementation defined. But it would be nice, to add an _additional_
symbol, which has a defined value for the implemented version of the
SystemC API. (Which is, what Jerome proposed, I think).

Something like:

// implements IEEE 1666-2010:
#define SYSTEMC_IEEE_1666 201001L

The LRM could simply state, that "An implementation shall define the
preprocessor symbol SYSTEMC_IEEE_1666 to 201001L."

For quality of implementation purposes, "older" implementations could
then add this as well and define it as 200501L, for instance. (Which
culd be part of a note in the LRM).

In future versions of SystemC, this value would then be incremented
accordingly, e.g. 201501L for 2015.

Thanks,
  Philipp

On 05/10/10 14:42, john.aynsley@doulos.com wrote:
> All,
>
> Please see the email below. We are running out of time on this one. We
> need to start getting some things pinned down.
>
> In summary, TLM-2.0 has a list of macros and functions, SystemC has just
a
> few functions. We need to maintain near-100% backward compatibility at
> the source code level, but we have some flexibility as to exactly what
we
> do or do not include in P1666. For example, we do not need to include
ALL
> of the TLM-2.0 macros and functions in P1666 (if this helps). We agree
we
> want macros for SystemC as well as TLM-2.0.
>
> We need to decide in principle whether the information returned from
these
> macros and functions is implementation-defined (with respect to P1666)
or
> whether P1666 is going to mandate anything (which might be related to
one
> of Jerome's questions, if I understand correctly) In other words, we
need
> to decide whether P1666 is going to put any constraints on the values
> returned from the two sets of macros/functions by an implementation. If
> not, our work could be almost done: we just need to select a set of
> macros/functions to go into the LRM.
>
> Please chip in, everybody.
>
> John A
>
> ----- Forwarded by John Aynsley/doulos on 05/10/2010 13:33 -----
>
> From:
> john.aynsley@doulos.com
> To:
> Jerome CORNET <jerome.cornet@st.com>
> Cc:
> "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
> Date:
> 05/10/2010 10:45
> Subject:
> RE: Version number macros
> Sent by:
> owner-systemc-p1666-technical@eda.org
>
>
>
> Jerome,
>
> I neither agree nor disagree, but I am still not sure exactly what
changes
> you are proposing. Could you spell it out for me, please?
>
> To spell out my position, so far I am only working to the following
> principles
>
> * We want backward-compatibility (thought perhaps 99% is good enough)
with
> both the SystemC and TLM-2.0 LRMs and implementations
> * We want separate versions (etc) for SystemC and TLM-2.0 rather than a
> single merged set
> * The resultant two sets of definitions should be mutually consistent
>
> I would also note that we are not obliged to put the full set of
> definitions (as found in the two OSCI implementations) within the P1666
> LRM. We could chose a subset. We do not necessarily want P1666 to be
> highly specific since it may (or may not) end up with multiple
> implementations.
>
> Are you suggesting the P1666 should mandate specific values for the
> version API to indicate either 1666 or TLM-2.0 compliance (whatever that

> would mean, opening a can of worms!)
>
> Thanks,
>
> 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:
> 05/10/2010 10:04
> Subject:
> RE: Version number macros
>
>
>
>
> John,
>
> sorry to insist... I perfectly understand that SYSTEMC_VERSION_* macros
> are a way to identify a specific implementation version within a
vendor?s
> lineage.
>
> However, I do think that applying the same reasoning to the
TLM_VERSION_*
> macros does neither seem to be useful nor logical. Whereas it is true
> that TLM itself can be implemented ?differently? by each vendor (to add

> specific instrumentations, etc.), particular implementations details
> can already be identified through the SystemC version macros, and it is
> important to be able, say, to rely on TLM_VERSION_MAJOR being 2 or
> greater
> to be sure that TLM-2 itself is implemented. Isn?t it?
>
> Jerome
>
> From: owner-systemc-p1666-technical@eda.org [
> mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of
> john.aynsley@doulos.com
> Sent: Monday, October 04, 2010 6:14 PM
> To: systemc-p1666-technical@eda.org
> Subject: RE: Version number macros
>
> To answer Jerome, sure, the actual choice of version numbers is
> implementation-defined. The standard only defines the formal structure.
> The OSCI simulator follows a specific lineage of version numbering.
Other
> vendors may base their versions on the OSCI numbering or may do their
own
> thing. These strings relate to the implementation itself, NOT to the
> version of the IEEE standard the implementation claims to support. That
> would be presumptuous!
>
> Does that work?
>
> John A
>
>
>

-- 
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.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.