RE: Empty events lists

I agree with making these cases errors, just to avoid confusion for users. However, I strongly recommend the errors are configurable (ie sc_report_handler::set_actions() or similar ), say to disable throwing an exception. I don't know what kind of language could be used in the LRM to encourage implementations to do that.

It's very annoying to be gated while debugging due to an unrelated error (that may be in code not under your control).

EricR

________________________________
From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of john.aynsley@doulos.com
Sent: Tuesday, November 02, 2010 11:51 AM
To: Philipp A Hartmann; bpriya@cadence.com
Cc: david.long@doulos.com; p.goel@acm.org; P1666 Technical WG
Subject: Re: Empty events lists

All,

Okay, so I propose that wait(empty_list) and wait(delay, empty_list) are both errors. Agreed?

(But otherwise I could live with Bishnupriya's error/warning proposal)

John A

-----"Philipp A. Hartmann" <philipp.hartmann@offis.de> wrote: -----
To: john.aynsley@doulos.com
From: "Philipp A. Hartmann" <philipp.hartmann@offis.de>
Date: 11/02/2010 09:45AM
Cc: p.goel@acm.org, david.long@doulos.com, P1666 Technical WG <systemc-p1666-technical@eda.org>
Subject: Re: Empty events lists

John, All

since wait() typically means 'wait for static sensitivity, if present',

'wait(empty_list)' should at least NOT degenerate to 'wait()'.

  If we really want to add some semantics, I think we definitely need to

warn the user to avoid accidental confusion. So to combine this with

Puneet's proposal, this could mean:

  wait( empty_or_list ) => warn and wait forever

                            (Any event fired? No. => Wait)

  wait( empty_and_list ) => warn and return immediately

                            (All events fired? Yes. => Return)

  wait( delay, empty_or_list ) => warn and wait( delay )

  wait( delay, empty_and_list ) => warn and return immediately

But maybe it's easier to simply error out in all cases, since the user

can easily work around this as shown in my earlier mail. I tend to

prefer this.

Greetings from Oldenburg,

  Philipp

On 02/11/10 17:30, john.aynsley@doulos.com wrote:

> Puneet, Bishnupriya, All,

>

> I too understand what Puneet is saying. But SystemC event lists are not lists in a functional programming sense, and the typical SystemC user is not a functional programmer. On the other hand, there are existing semantics and clear expectations attached to wait(), i.e. it means wait forever.

>

> So, now we introduce explicit wait lists, allowing constructs such as wait(list) or wait(delay, list). If the list is empty, I think for SystemC users there are 3 obvious choices we could make

>

> - wait(empty_list) => wait forever

> - wait(empty_list) => error

> - wait(empty_list) => warning and wait forever

>

> Bisnupriya has proposed

> - wait(empty_list) => error

> - wait(delay, empty_list) => warning and wait(delay)

>

> I am not entirely comfortable with having the first as an error and the second as a warning. It's not a show-stopper for me, but if we are not going to have wait(empty_list) wait forever, then I would prefer both forms to be an error. It seems more straightforward.

>

> John A

>

>

>

> -----puneet@coverify.com wrote: -----

> To: "Philipp A. Hartmann" <philipp.hartmann@offis.de>

> From: Puneet Goel

> Sent by: puneet@coverify.com

> Date: 11/02/2010 04:11AM

> Cc: david.long@doulos.com, john.aynsley@doulos.com, owner-systemc-p1666-technical@eda.org, systemc-p1666-technical@eda.org

> Subject: Re: Empty events lists

>

>> It is like when you define an operation on a list, you start with a

>> seed.

>

> Like in case of summation on a list you start with the result seeded

> to 0. In case of multiplication (factorial) you start with the result

> seeded to 1. In case of ORing a list, we start with the result seeded

> to false. And in case of ANding a list, we start with the result

> seeded to true.

>

> Similarly is we think about sc_event_and_list, we would seed the

> result with an immediate event. And for sc_event_or_list, we should

> seed the result with an event that never gets notified.

>

> Regards

> - Puneet

>

>

>

--
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
Phone/Fax: +49-441-9722-420/282 * PGP: 0x9161A5C0 * http://www.offis.de/
--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.