Re: Auto-increment proposal with example


Subject: Re: Auto-increment proposal with example
From: Michael McNamara (mac@verisity.com)
Date: Thu Jan 09 2003 - 08:37:38 PST


It is impossible to consider your proposed changes without answering
Paul's questions, which I reiterate myself herein, with slightly
different focus.

Karen Pieper writes:
> Hi, all,
>
> Paul's comments are the only ones I've received on the proposal I
> originally sent. His comments were on the original unmodified
> paragraph that I was using to indicate where to add the new
> paragraph. I will add his comments as a new issue for us to track.
> Since there were no changes to the proposed new wording, and there
> exists a second, we can vote on this proposal. If there are no
> comments on the new wording (not the existing wording) by
> Wednesday, January 15 at 6:00pm PST, the proposal will pass.
>
> Thanks,
>
> Karen
>
> Increment decrement proposal:
> In Section 7.3:
> REPLACE: SystemVerilog also includes the C incrementor and decrementor
> operators ++i, --i, i++ and i-- (provided there is no timing control). These
> can be used in expressions without parentheses. These increment and
> decrement operations behave as blocking assignments.
>
> WITH: SystemVerilog also includes the C incrementor and decrementor
> operators ++i, --i, i++ and i-- (provided there is no timing
> control). These can be used in expressions without parentheses.

 What does this preceding statement mean? Does it mean that these
 autoincrement/autodecrement constructs can not be used in statements
 that do have parentheses?

 => If it does not mean this, then let us delete the sentence, as it
   adds no value to the standard.

 => If it does mean this, let us instead say:

   'These operators can not be used in expressions that include
    parentheses.'

> These increment or decrement operations behave as blocking
> assignments.
>
> <new paragraph>
> The ordering of assignment operations relative to any other
> operation within an expression is undefined. An implementation may
> warn whenever a variable is both written and read-or-written within
> an integral expression or in other contexts where an implementation
> cannot guarantee order of evaluation. Consider the following
> example:
> i = 10;
> j = i++ + (i = i - 1);
> After execution, the value of j can be 18, 19, or 20 depending upon
> the relative ordering of the increment and the assignment
> statements.

 I see how to get 18, and to get 20:

    j = ((9 = 10 -1) + (9++)) => j gets 18, i gets 10
    j = (10++ + ( 10 = 11 - 1 )) => j gets 20, i gets 10

 but I don't see how to get 19, as the ++ operator I know from C is an
 atomic operator.

 If however the previous sentence under discussion, 'These
 (autoincrement/autodecrement) can be used in expressions without
 parentheses.' means indeed that they can not be used in expressions
 that do have parenthesis, that would make the above expression
 illegal, hence a moot point, n'est ce pas?

> At 05:33 PM 1/6/03 -0800, Paul B. Graham wrote:
> > > WITH: SystemVerilog also includes the C incrementor and
> > > decrementor operators ++i, --i, i++ and i-- (provided there is
> > > no timing control). These can be used in expressions without
> > > parentheses. These increment or decrement operations behave as
> > > blocking assignments.
> >
> >Why the difference between:
> >
> > ... include the C incrementor and decrementor operators ...
> >
> >and
> >
> > ... These increment or decrement operations ...
> >
> >Why not use the same wording?
> >
> >Does "provided there is no timing control" mean "provided there is
> >no timing control in the design"? Or does it mean that inc/dec
> >cannot be used within a delay expression?
> >
> >Why say they can be "used in expressions without parentheses"?
> >Does this mean they cannot be used in expressions with
> >parentheses? For instance, are
> >
> > x = (i++);
> > y = i++ + (j);
> >
> >illegal? Is the intent to say that inc/dec can only be applied to an
> >lvalue?
> >
> >Paul
>
>



This archive was generated by hypermail 2b28 : Thu Jan 09 2003 - 08:38:44 PST