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.