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.