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