Fw: Version number macros

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

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