RE: [Systemc-board] RE: [Systemc-lrmdev] Re: SystemC Study Group Agenda and docs for review

Certainly the debate over SystemC being a language or a C++ class library will continue, but in the context of the IEEE, I believe the focus is on it being a language which can be adequately documented.

However, it does open a large number of questions as to how does the LRM relate to the open source. Since they seem to go hand-in-hand, it is necessary for the SystemC 2.0.1 source to be given to the IEEE? In order for the Study Group to meet, should the open source be offered under the same openness rules as outlined in the IEEE-SA Operation Manual clause 4.1.1.5?

There are several other DASC standards in the IEEE which do have source. In the case of VITAL (1076.4), the document served as written reference to the code, but in a dispute, the code prevailed. As such, the code was included as a clause in the specification.

In the case of the Delay and Power Calculation System (DPCS and IEEE 1481), the header files were included in the specification to ensure interoperability. Should systemc.h be included to offer a minimum level of interoperability? If so, should it too not be made open in keeping with the IEEE-SA Opts Man clause 4.1.1.5?

My view on this will be that at a minimum the header file(s) should be part of the standard and that the documentation should better reflect the specification of SystemC calls based on the header file information. This would permit alternate, competitive implementations that are not dependent on the open source version. The last thing the IEEE would tolerate is the use of it as a method to funnel users, consumers and suppliers to OSCI for the open source since the LRM may be insufficient and incomplete to support the scope.

-Dennis

-----Original Message-----
From: systemc-board-admin@systemc.org [mailto:systemc-board-admin@systemc.org] On Behalf Of Stuart Swan
Sent: Saturday, August 07, 2004 12:37 PM
To: David Barton; stds-dasc@eda.org
Cc: systemc-board@systemc.org; systemc-lrmdev@systemc.org; steve_mills@hp.com; e.rashba@ieee.org; wcadams@us.ibm.com; john.aynsley@doulos.com
Subject: [Systemc-board] RE: [Systemc-lrmdev] Re: SystemC Study Group Agenda and docs for review

All-

The latest SystemC LRM (which, BTW, is newer than the one currently available on the SystemC website) clearly states that SystemC is a C++ class library. Moreover the LRM simply references the ISO C++ standard -- it does not try to replicate any of it.

I'll leave it to others to argue whether SystemC should properly be called a "language" in its own right. Since SystemC is seeing widespread and growing use, many people now see that standardization of the class library's API thru IEEE will provide many benefits.
Note that the LRM and the standard will be independent of any particular SystemC implementation, including the current OSCI reference implementation.

-Stuart

>-----Original Message-----
>From: systemc-lrmdev-admin@systemc.org
>[mailto:systemc-lrmdev-admin@systemc.org] On Behalf Of David Barton
>Sent: Friday, August 06, 2004 5:14 AM
>To: stds-dasc@eda.org
>Cc: systemc-board@systemc.org; systemc-lrmdev@systemc.org;
>steve_mills@hp.com; e.rashba@ieee.org; wcadams@us.ibm.com;
>john.aynsley@doulos.com
>Subject: [Systemc-lrmdev] Re: SystemC Study Group Agenda and docs for
>review
>
>While I will not be able to attend, and will not be able to be a member
>of the working group due to time constraints, I feel I must make a
>purely technical comment.
>
>Kamal Hashmi writes:
>
>> First of all, SystemC is a set of libraries and templates in a
>> standard language, not a language itself. Is it appropriate to make
>> this a static copyrighted standard for payment rather than an
>> evolving de-facto free standard ? Certainly a set of interfaces can
>> be a standard.
>
>I must disagree here, Kamal. This mechanism of defining a language by
>embedding it inside another language, using libraries, type
>definitions, and other definitions of the embedding language is
>referred to as a Domain Specific Embedded Language (DSEL). It is
>becoming much more common as a language defining mechanism, and there
>is a growing body of literature on the subject. Several DSELs have
>been defined using Haskell as a base, including Lava and the Signal and
>Measurement Modelling Language (SMML) that was used as part of ATLAS
>2000. I must emphasize that these are not "sublanguages" or
>"superlanguages", but separate languages with a shared grammar. A
>search of the literature on DSEL will show how this is becoming much
>more common for domain specific languages, as it has many
>advantages:
>no need to make separate tools and you can use the semantics of the
>existing language to define the semantics of the new language. In many
>cases, there is no need for the entire syntax of the embedding
>language, and a simplified LRM using only the structures of the DSEL
>can be written. The LRM can be independent, or can refer to the
>embedding language LRM, depending on the needs of the committee.
>
>Dave Barton
>EDAptive Computing
>
>
>
>_______________________________________________
>Systemc-lrmdev mailing list
>Systemc-lrmdev@systemc.org
>https://www.systemc.org/mailman/listinfo/systemc-lrmdev
>
>

_______________________________________________
Systemc-board mailing list
Systemc-board@systemc.org
https://www.systemc.org/mailman/listinfo/systemc-board
Received on Sun Aug 8 22:03:45 2004