RE: Version number macros

John, all,

sure there is the existing version API to work out.

In my view (please correct me if I misunderstood the current norm):

- The SystemC API (sc_version(), etc.) defines every version number and string

as implementation-specific. This means that at best, the user can test version numbers

for a given vendor implementation (for instance to benefit extra features not defined

in the norm), but there is no relation with the norm or the OSCI implementation. Plus,

there are the various drawbacks mentioned.

- The "TLM" is better (agreed with you David), but I am still not very comfortable with
the "implementation-defined" everywhere. Maybe I misunderstood, but what
prevents a new vendor to define TLM_VERSION_MAJOR as 1 whereas it is implementing
TLM-2?

And there is the problem of backward compatibility.

 So, I would rather be in favor of:

- defining separate macros for the IEEE revision (2005, 2010, etc.)
 (and potentially API for use at runtime, to be homogeneous with SystemC and TLM APIs)

- Keep the TLM and SystemC version APIs (no merge)

- Improve the SystemC version API while trying to keep backward compatibility (David

will have more clear ideas of what to do).

The IEEE API is useful to write implementation independent code, while distinguishing

between the various features offered by the revisions of the norm.

The SystemC API is finer-grained, to test for a vendor specific version.

Regarding the TLM API I don't know: is it the same as SystemC, or can we test the TLM-2 evolution with it??

Comments, opinions welcomed...

Jerome

From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Tuesday, September 28, 2010 1:17 PM
To: Jerome CORNET; systemc-p1666-technical@eda.org
Subject: Re: Version number macros

Jerome, All,

Well, okay, but there is more to it than that. Here is the current SystemC API. Note that there are no macros, but the release string has a formal structure.

namespace sc_core {
const char* sc_copyright();
const char* sc_version();
const char* sc_release();
}

Function sc_release shall return an implementation-defined string of the following form:
<major#>.<minor#>.<patch>-<originator>
where <major#> represents the major release number, <minor#> represents the minor release
number, <patch> represents the patch level, and <originator> represents the originator of the
SystemC implementation. The intent is that this string should be machine-readable by any SystemC
application that has an interest in checking the version or release number of the SystemC
implementation.
The character set for each of these four fields shall be as follows:
a)The lower-case letters a-z
b)The upper-case letters A-Z
c)The decimal digits 0-9
d)The underscore character _

and here is the equivalent for TLM-2.0 (taken from the OSCI LRM, not just the implementation):

namespace tlm
{
#define TLM_VERSION_MAJOR implementation_defined_number // For example, 2
#define TLM_VERSION_MINOR implementation_defined_number // 0
#define TLM_VERSION_PATCH implementation_defined_number // 1
#define TLM_VERSION_ORIGINATOR implementation_defined_string // "OSCI"
#define TLM_VERSION_RELEASE_DATE implementation_defined_date // "20090329"
#define TLM_VERSION_PRERELEASE implementation_defined_string // "beta"
#define TLM_IS_PRERELEASE implementation_defined_bool // TRUE
#define TLM_VERSION implementation_defined_string // "2.0.1_beta-OSCI"
#define TLM_COPYRIGHT implementation_defined_string

const unsigned int tlm_version_major;
const unsigned int tlm_version_minor;
const unsigned int tlm_version_patch;
const std::string tlm_version_originator;
const std::string tlm_version_release_date;
const std::string tlm_version_prerelease;
const bool tlm_is_prerelease;
const std::string tlm_version_string;
const std::string tlm_copyright_string;

inline const char* tlm_release();
inline const char* tlm_version();
inline const char* tlm_copyright();
} // namespace tlm

So the question is, do we want independent and parallel set of definitions for SystemC and TLM-2.0 releases, or do we want to merge them to give a single combined version? Having made that decision, do we want backward compatibility with the current 1666 and TLM-2.0 definitions?

John A

From:

Jerome CORNET <jerome.cornet@st.com>

To:

"Philipp A. Hartmann" <philipp.hartmann@offis.de>

Cc:

john.aynsley@doulos.com, systemc-p1666-technical@eda.org

Date:

16/09/2010 13:59

Subject:

Re: Version number macros

________________________________

  Philipp,

sorry for the delay in the answer: obviously you are right (I should
have read the C++ norm more
carefully).

Agreed with all you said.

Regards,

Jerome

On 9/15/2010 11:29 AM, Philipp A. Hartmann wrote:
> Jerome,
>
> according to the C++ standard (17.4.3.1.2 [lib.global.names]), "certain
> sets of names and function signatures are always reserved to the [C++]
> implementation":
>
> - Each name that contains a double underscore (__) or begins with an
> underscore followed by an upper-case letter (2.11) is reserved to
> the implementation for any use.
>
> So I would prefer to have a macro name like SYSTEMC_IEEE_VERSION, or
> SYSTEMC_IEEE_1666. SYSTEMC_VERSION should not be used, since this is
> already used in (some) existing implementations.
>
> Thanks,
> Philipp
>
> On 14/09/10 13:17, Jerome CORNET wrote:
>> On 9/10/2010 4:07 PM, john.aynsley@doulos.com wrote:
>>> Jerome,
>>>
>>> After process control extensions, the next priority on the list is
>>> version number macros.
>>>
>>> You wrote:
>>>
>>> "Speaking of macros, I don't know if this has been planned, but it
>>> would be great (and standard practice) to specify a way to retrieve
>>> the version number of the norm that an implementation is following.
>>> (In our case that would be either 2005 or 2010 for now).
>>> The ISO C standard defines a macro __STDC__VERSION__ whose value is
>>> 199901L (integer long) for C99.
>>> ISO C++ also defines a macro, __cplusplus with value 199711L."
>>>
>>> Would you like to make a specific proposal?
>>>
>> John, All, (sorry for the slight delay)
>>
>> to me the best way is to follow the other standards' previous decisions
>> unless
>> we've got strong reasons for changing.
>>
>> So I would propose a macro (to allow test in #if) like this:
>>
>> __SYSTEMC_IEEE_VERSION with value 201001L
>>
>>
>> with 2010 be for 1666-2010 and 01 being reserved for minor revisions (as
>> it is used for c++).
>>
>> If someone prefer a variations in the name (__SYSTEM_VERSION or
>> whatever), this is obviously
>> also ok for us.
>>
>>
>> Jerome
>>
>>
>>
>

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