RE: [sv-ac] 928 Proposal Updated

Hi,

It seems to me that the definition of what is const, pass by value, pass
by substitution and pass by reference (isn't that the same as
substitution?) will make it quite complicated. Yet, pass by value will
anyway introduce a local variable, but implicitly. Perhaps that could be
left to the user - explicit user-defined local var if by value is
needed. Therefore, adding sequence, property and void as a type (in
addition to untyped with the restriction that is already in the
proposal) might be ok. All is still passed by substitution, the types
are only used to make sure that a type error is not detected only once
the actual arg is substituted in the use context.

so... leaving aside the 3 new types, it seems to me that the proposal as
it stands now on Mantis is sufficient... and I'd vote yes for that
one...

ed



> -----Original Message-----
> From: John Havlicek [mailto:john.havlicek@freescale.com] 
> Sent: Wednesday, June 28, 2006 8:09 AM
> To: piper@cadence.com
> Cc: Bassam.Tabbara@synopsys.COM; john.havlicek@freescale.com; 
> Eduard.Cerny@synopsys.COM; dmitry.korchemny@intel.com; 
> Brad.Pierce@synopsys.COM; sv-ac@eda-stds.org
> Subject: Re: [sv-ac] 928 Proposal Updated
> 
> Hi Lisa:
> 
> Between alternatives 1 and 2, I strongly favor fixing 
> this now.
> 
> I like the direction of the proposal you have outlined.
> 
> I think we will have to put some more thought into 
> how "const" works as a type and whether we allow "const"
> with other types.
> 
> We should also think about the fact that pass-by-value 
> is the default for tasks and functions, while pass-by-reference
> is the mechanism for typed arguments to sequences and 
> properties and pass-by-substitution is the mechanism 
> for untyped (and presumably, void, sequence, and property)
> arguments.
> 
> Even if we do not add pass-by-value as a part of this
> solution, I think we should have a clear idea of how 
> to add it later.
> 
> How does the argument passing work in PSL?
> 
> Best regards,
> 
> John H.
> 
> 
> > X-MimeOLE: Produced By Microsoft Exchange V6.5
> > Content-class: urn:content-classes:message
> > Date: Tue, 27 Jun 2006 14:40:40 -0400
> > X-MS-Has-Attach: 
> > X-MS-TNEF-Correlator: 
> > Thread-Topic: [sv-ac] 928 Proposal Updated
> > Thread-Index: AcaaDNZwVdRAZQUnSKCvR9WVy8Q16wAA6K/gAAEJTfA=
> > From: "Lisa Piper" <piper@cadence.com>
> > Cc: <Eduard.Cerny@synopsys.com>, <dmitry.korchemny@intel.com>,
> >         <Brad.Pierce@synopsys.com>, <sv-ac@eda-stds.org>
> > X-Received: By mx-sanjose.cadence.com as k5RIef8N010126 at 
> Tue Jun 27 11:40:42 2006
> > X-OriginalArrivalTime: 27 Jun 2006 18:41:57.0873 (UTC) 
> FILETIME=[5E9B3E10:01C69A19]
> > 
> > Hi all,
> > 
> > I think the earlier we make these types of changes, the 
> less impact it
> > will have on users. This implies that IF we do it, we need 
> to do it now.
> > I am for fixing it now!
> > 
> > Personally I think the four big "holes" that are needed to fix this:
> > 
> > 	void      for untyped parameters when used in this context
> > 	property  for properties
> > 	sequence  for sequences
> > 	const     for constant integers for repetition and delays
> > 
> > Using this terminology does not create any new keywords so there is
> > minimal change. I would make the default type "void" to help with
> > backwards compatibility issues (this is different as 
> Manisha pointed out
> > than the default type of logic for functions/tasks).
> > 
> > I'm not sure whether people care, but PSL does not allow untyped
> > parameters, and their syntax for arguments is like 
> tf_port_list.  PSL
> > uses the keywords property, sequence, and const for arguments.
> > 
> > So the questions are:
> > 
> > 1) should we do this now - that is make the port list 
> consistent with
> > tf_port_list format AND add new types to the list of 
> allowed type names.
> > 	- add all 4 types?
> > 	- are the type names ok?
> > 	- is the default of "void" ok?
> > 
> > 2) strip it out and live with it forever
> > 
> > 3) other?
> > 
> > Lisa
> > 
> > 
> > 
>