RE: [sv-ec] rewording 1615

There are some cases where you don't want to allow an error during
compile time, like null handle dereferences. Things like syntax errors
and unresolved references we say are illegal and we do want to get past
elaboration. The 2008 LRM now has some mention of compilation and
elaboration, but the two key phases are compilation up until the end of
elaboration, and post-elaboration (i.e. run-time).

If an implementation wants to be true to the LRM, they only have one
choice in the above cases where to issue the error; either pre- or
post-elaboration. 

In the case of 1615, and well as a few other places, the intent is that
we would like the error to be caught pre-elaboration, but we have
conceded that there are cases where is too difficult to catch there
error until run-time.


Dave

> -----Original Message-----
> From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org]
On
> Behalf Of Bresticker, Shalom
> Sent: Tuesday, September 11, 2007 6:33 AM
> To: Bresticker, Shalom; Geoffrey.Coram; sv-ec@server.eda.org
> Subject: RE: [sv-ec] rewording 1615
> 
> Also:
> 
> Is the following sentence needed: "Implementations shall issue an
error
> either at compile time or run time when they have determined the
illegal
> condition."?
> 
> That is, if we don't say anything, can't the implementation issue the
> error when it wants? Especially if the intent is to say that it is
> allowed to issue the error at compile time, would anyone think it is
> forbidden if the sentence is not there? In most places, we don't
specify
> when an error should occur.
> 
> Shalom
> 
> 
> > -----Original Message-----
> > From: owner-sv-ec@server.eda.org
> > [mailto:owner-sv-ec@server.eda.org] On Behalf Of Bresticker, Shalom
> > Sent: Tuesday, September 11, 2007 4:21 PM
> > To: Geoffrey.Coram; sv-ec@server.eda.org
> > Subject: RE: [sv-ec] rewording 1615
> >
> > Geoffrey,
> >
> > 1. The objection came from me. I did not suggest leaving only
> > the condition about initial blocks. In an earlier comment, I
> > had suggested the following:
> >
> > "Calling a function that executes a fork..join_none block
> > shall be legal only in procedural code originating in an
> > initial block and illegal in any context in which a side
> > effect is disallowed."
> >
> > This is more or less the same as your version. Both versions
> > are clearer than the current text. Until this is fixed, I
> > will continue to vote against this at the Champions level.
> >
> >
> > 2. I had also commented:
> > Is there a difference between "originating in an initial
> > block" and "in an initial block"? If so, are readers going to
> > understand the difference?
> >
> >
> > 3. Also:
> > The 1615 proposal says, "Calling a function that executes a
> > fork..join_none block shall be illegal in any context in
> > which a side effect is disallowed or any context other than
> > procedural code originating in an initial block."
> >
> > The 1336 proposal says, "A function that tries to schedule an
> > event that will become active only after that function
> > returns shall be an error in any context in which a side
> > effect is disallowed or in any context other than a thread
> > originating in an initial or always block."
> >
> > The 1615 proposal does not mention always procedures and the
> > 1336 proposal does. Is that correct?
> >
> >
> > 4. Note also that initial and always_comb "blocks" should be
> > called "procedures".
> >
> > Regards,
> > Shalom
> >
> >
> > > -----Original Message-----
> > > From: owner-sv-ec@server.eda.org
> > > [mailto:owner-sv-ec@server.eda.org] On Behalf Of Geoffrey.Coram
> > > Sent: Tuesday, September 11, 2007 3:50 PM
> > > To: sv-ec@server.eda.org
> > > Subject: [sv-ec] rewording 1615
> > >
> > > Per Neil's e-mail (http://www.eda-stds.org/sv-ec/hm/4675.html),
> > > the Champions did not like the wording of this sentence:
> > >
> > >    Calling a function that executes a fork..join_none block
> > >    shall be illegal in any context in which a side effect is
> > >    disallowed or any context other than procedural code
> > >    originating in an initial block.
> > >
> > > Note that this is not the same as
> > >    Calling a function that executes a fork..join_none block
> > >    shall be legal only in procedural code originating in an
> > >    initial block.
> > > (which is what I thought one of the Champions suggested)
> > because the
> > > procedural code may still be in a context in which a side effect
is
> > > disallowed.
> > >
> > > I think that this:
> > >    A function that executes a fork..join_none block shall only
> > >    be called in procedural code originating in an initial
> > >    procedure and in a context in which side effects are allowed.
> > >
> > > captures both exclusions.  The following sentence reads:
> > >
> > >    Examples of such illegal contexts are continuous assignments,
> > >    nonblocking assignments, always_comb blocks, static variable
> > >    declaration initializers, elaboration-time calls, and
concurrent
> > >    assertions.
> > >
> > > (after changing "initialized" to "initializers" on the 3rd line).
> > >
> > > We took a vote (and I believe it passed, with 2 against) to
> > send the
> > > current proposal back to the Champions without changing
> > this sentence.
> > > Since I voted against, I felt obligated to propose an improvement.
> >
---------------------------------------------------------------------
> > Intel Israel (74) Limited
> >
> > This e-mail and any attachments may contain confidential
> > material for the sole use of the intended recipient(s). Any
> > review or distribution by others is strictly prohibited. If
> > you are not the intended recipient, please contact the sender
> > and delete all copies.
> >
> > --
> > This message has been scanned for viruses and dangerous
> > content by MailScanner, and is believed to be clean.
> >
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> 
> --
> 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.