Re: Draft P1666 LRM for review - updated

Yossi,

the current "immediate" semantics of the process control functions has
two aspects:

 1) effect in the current evaluation phase (which you are addressing)
 2) effect is completely processed, when function returns

  There has been strong support for the second property. And I think,
there's no sane way to keep (2) while loosening (1). It would even make
things worse, since you can no longer e.g. kill multiple processes
simultaneously without extra effort:

  h1.kill(); // my increment delta count (?)
  h2.kill(); // 2nd kill would be "later" (!)

  Since there hasn't been a strong enough movement to spend the required
effort to redefine the whole execution semantics wrt. (2), and now there
way too little time left for such a major change, I think we should keep
things as they are now.

Greetings from Oldenburg,
  Philipp

On 15/01/11 14:11, Veller, Yossi wrote:
> Hi John,
>
> Thanks for the explanation.
>
> So if the main motivation is implementation then why note leave the
> whether the semantics of the process control is immediate implementation
> dependent?
>
> In this way deterministic and parallelizable implementations can be
> standard compliant.
>
>
> Regards
>
> Yossi
>
>
>
> *From:*john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
> *Sent:* Friday, January 14, 2011 12:00 PM
> *To:* Veller, Yossi
> *Cc:* systemc-p1666-technical@eda.org; bpriya@cadence.com;
> philipp.hartmann@offis.de
> *Subject:* RE: Draft P1666 LRM for review - updated
>
>
>
> Hi Yossi,
>
> Yes, you've made that point before, and it is a valid one.
>
> Back in the early days, we did have a long and very explicit discussion
> about the immediate process control semantics, including reset(). Some
> of us thought that having delta cycle semantics throughout the process
> control extensions was the more natural approach, others thought that
> immediate semantics were right. We had the debate, and the conclusion
> was to go with the immediate semantics. Part of the rationale was that
> the process control extensions with immediate semantics have been
> prototyped and proven over a period of years (by Cadence and in the OSCI
> PoC simulator), and we did not want to rip the whole thing up.
>
> Practically, I do not think anyone (apart from you, clearly) is
> motivated to go in this direction right now, but people will have to
> speak for themselves...
>
> Cheers,
>
> John A
>
> From: "Veller, Yossi" <Yossi_Veller@mentor.com>
> To: <john.aynsley@doulos.com>
> Cc: <systemc-p1666-technical@eda.org>
> Date: 14/01/2011 02:30
> Subject: RE: Draft P1666 LRM for review - updated
>
> In 6.2.12 and 6.6.6.4 there is a reference for reset call and others
> having an immediate affect or during the current evaluation phase.
>
> Immediate notification is a source for dependence of the simulation
> results on the simulator’s scheduler and a basis for non parallelizable
> code (e.g. in such an implementation the reset action may come after the
> reset thread executes or before) . SystemC had chosen to provide
> immediate notification for the user to use upon his/her responsibility.
> However immediate notification should not be a ‘standard’ behavior of
> operations provided by the kernel.
>
> Then unless there are compelling reasons, e.g. from simulation speed
> degradation, I believe that the kill and reset effects**should be
> delayed to the next evaluation phase.
> The same should be applied to suspend (even though it becomes very close
> to disable).
>
> Regards
> Yossi

-- 
Philipp A. Hartmann
Hardware/Software Design Methodology Group
OFFIS Institute for Information Technology
R&D Division Transportation · FuE-Bereich Verkehr
Escherweg 2 · 26121 Oldenburg · Germany · http://www.offis.de/
Phone/Fax: +49-441-9722-420/282 · PGP: 0x9161A5C0 · Skype: phi.har

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