RE: Process Control Extensions - kill/reset/throw scheduling, exception handling

Jerome,

I'm not arguing for the insertion of any particular language that promotes a future multi-core implementation. However, I will argue against specifications that clearly place undue burdens on any such future implementation. It's a matter of putting in specifications that are reasonable in terms of achieving the intended goal as well as not overly restricting the future development of SystemC, or requiring us to re-write the specifications later (P1666-2015 anyone?) and thus possibly breaking existing models/implementations.

Best regards,

Tor Jeremiassen

---
Tor Jeremiassen, Ph.D.
Simulation and Modeling CTO
SDO Foundational Tools
Texas Instruments                    Ph:    281 274 3483
P.O. Box 1443, MS 730                Fax:   281 274 2703
Houston, TX 77251-1443               Email: tor@ti.com<mailto:tor@ti.com>
________________________________
From: Jerome CORNET [mailto:jerome.cornet@st.com]
Sent: Thursday, September 02, 2010 3:16 AM
To: john.aynsley@doulos.com
Cc: Philipp A. Hartmann; Bishnupriya Bhattacharya; Jeremiassen, Tor; Stuart Swan; owner-systemc-p1666-technical@eda.org; SystemC P1666 Technical
Subject: Re: Process Control Extensions - kill/reset/throw scheduling, exception handling
Agreed with John on all points. And for sanity of the debate, it would may be better to argue without "multi-core implementation" arguments for now...
I am not against leaving room for multi-core implementations at all (and indeed this is already in some points the current norm), but to have strong arguments, the arguments should be based on a clear and tested prototype of such an implementation... (and one would need to give at least a reasonable argument to explain why the changes required by the prototype are indeed valid in general for multi-core implementations).
And let's don't forget that parallelization of SystemC (or other languages' simulators) while keeping a behavior that do correspond to the language is subject to many scientific locks that, to my knowledge, have not been demonstrated to be solved recently...
Jerome
On 9/1/2010 2:22 PM, john.aynsley@doulos.com<mailto:john.aynsley@doulos.com> wrote:
All,
My opinion on this recent debate is pragmatic. The process control extension proposal has been around for a few years now and has been prototyped by Cadence and within the OSCI POC sim, and I assume it is fit-for-purpose. I am opposed to trying to re-engineer a "better" solution within the P1666 Working Group along the lines Phillipp suggests (regardless of whether Phillipp's arguments are valid).
For what it is worth, I did find the immediate semantics of kill/reset to be "surprising", and would have expected them to work more like Phillipp suggests.
I take seriously the possibility of re-engineering SystemC in the future to exploit many-core processing. However, IMHO the necessary changes will be so radical that the inclusion of the proposed process control extensions will make little difference.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.