RE: Empty events lists

Agreed with that (error for both).

There is great risk of confusion here, and as Phlipp pointed out, the functionality that Puneet wanted can still be implemented with a user class.

Jerome

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 7:51 PM
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.