Re: reset method

I assume the method would be part of the exception.

------------------------------------------------------
David C Black, XtremeEDA ESL Practice Leader

On Jul 23, 2010, at 9:17 AM, Bishnupriya Bhattacharya wrote:

> John,
>
> I like this. Lets go with this solution.
>
> Thanks,
> -Bishnupriya
>
> From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
> Sent: Friday, July 23, 2010 7:43 PM
> To: Bishnupriya Bhattacharya
> Cc: David C Black; systemc-p1666-technical@eda.org
> Subject: RE: reset method
>
> Bishnupriya,
>
> I would prefer to rename sc_kill_exception to sc_unwind_exception to make the name neutral with respect to kill() and reset(), throw the same exception for both, and add a method bool is_reset() that could be tested in a catch block (under exceptional circumstances ;-)
>
> John A
>
>
>
> From: Bishnupriya Bhattacharya <bpriya@cadence.com>
> To: "john.aynsley@doulos.com" <john.aynsley@doulos.com>
> Cc: David C Black <dcblack@xtreme-eda.com>, "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
> Date: 22/07/2010 20:16
> Subject: RE: reset method
>
>
>
>
> John,
>
> I think you have a valid use case in mind, and the standard will indeed be cleaner with a way to distinguish between the two.
>
> How best to go about it?
>
> Since the exception is really for stack unwinding, should we have an abstract base class sc_unwind_stack_exception with pure virtual member is_reset(), and have sc_reset_exeception and sc_kill_exception both derive from this base class? Typically, user code won't need to distinguish between kill and reset, and can only catch sc_unwind_stack_exception. Code that wants to distinguish (likely the kernel) can catch the more derived classes.
>
> The alternative of having reset_exception derive from kill_exception or vice versa might be a little confusing/misleading, as neither functionality is a strict subset or superset of the other.
>
> If we wanted to really keep it simple, and not deviate much from the current spec, I think the purpose is also served (perhaps not so elegenatly) by only having the sc_kill_exception class, and giving it a member method "bool is_reset()" that returns false for kill and true for reset.
>
> Thoughts? Is a separate sc_unwind_stack_exception class an overkill? Or an overreset :-)
>
> Thanks,
> -Bishnupriya
>
>
> From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
> Sent: Thursday, July 22, 2010 10:56 PM
> To: Bishnupriya Bhattacharya
> Cc: David C Black; systemc-p1666-technical@eda.org
> Subject: RE: reset method
>
> Bishnupriya,
>
> Yes, but I don't have any specific agenda here other than creating a clean standard. I have not got any burning issues in mind. I guess that most of the time there would be no reason to distinguish between the two kinds of cleaning up, but I can imagine that a process that was collecting diagnostic information might want to handle it differently for a reset versus a kill, e.g. perhaps retain some diagnostic state information across the reset.
>
> John A
>
> From: Bishnupriya Bhattacharya <bpriya@cadence.com>
> To: "john.aynsley@doulos.com" <john.aynsley@doulos.com>, David C Black <dcblack@xtreme-eda.com>, "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
> Date: 22/07/2010 18:05
> Subject: RE: reset method
>
>
>
>
>
> John,
>
> Let me understand your objective better. You want that while a process is being killed/reset, there be some way of telling which is happening? For example, if the process itself catches sc_kill_exception, and wants to do one kind of cleanup or another based on whether it is getting killed or reset. Is that the objective?
>
> Thanks,
> -Bishnupriya
>
> From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
> Sent: Thursday, July 22, 2010 9:14 PM
> To: David C Black; Bishnupriya Bhattacharya; systemc-p1666-technical@eda.org
> Subject: Re: reset method
>
> Bishnupriya,
>
> It's nice to be able to catch and handle kills and resets, but I don't think it's important enough to justify anything but the simplest mechanism. I would have thought that most of the time kills and resets could be handled in the same way.
>
> I was musing on some other way of telling whether the process had been killed or reset, and method terminated() came to mind, but presumably a killed process would not get terminated until the exception was caught by the kernel, so that's no good.
>
> I am arguing semantics here, but if we have a common exception, that exception does not necessarily terminate the process, because it is being used for both reset() and kill(): reset() does not leave the process terminated. So having class sc_kill_exception: public sc_reset_exception makes more sense to me, with the sc_reset_exception actually doing the work of unwinding the stack. Does that work?
>
> John A
> From: David C Black <dcblack@xtreme-eda.com>
> To: systemc-p1666-technical@eda.org
> Date: 21/07/2010 21:16
> Subject: Re: reset method
> Sent by: owner-systemc-p1666-technical@eda.org
>
>
>
>
>
>
> If you're going to throw an exception anyhow, then I would prefer the sc_reset_exception solution over adding another member method.
>
> ------------------------------------------------------
> David C Black, XtremeEDA ESL Practice Leader
> http://www.Xtreme-EDA.com
> (Consulting, Services & Training for all your ESL, verification and DFT needs)
> Voice: 512.850.4322 Skype:dcblack FAX: 888.467.4609
>
> On Jul 21, 2010, at 2:49 PM, Bishnupriya Bhattacharya wrote:
>
> John,
>
> Yes reset() throws an sc_kill_exception.
>
> It is a good idea to distinguish reset from kill by using the exception. I suggest a member method in the sc_kill_exception class - "bool reset()" - or perhaps have sc_reet_exception that derives from sc_kill_exception?
>
> WDYT?
>
> Thanks,
> -Bishnupriya
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.

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