Re: Auto-increment proposal with example


Subject: Re: Auto-increment proposal with example
From: Karen Pieper (Karen.Pieper@synopsys.com)
Date: Thu Jan 09 2003 - 11:37:57 PST


Hi, all, I've enclosed comments on Michael McNamara's mail below.

At 08:37 AM 1/9/03 -0800, Michael McNamara wrote:

>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.'

The paragraph preceding this paragraph in question adds the ability of
an expression to include a blocking assignment provided that the
assignment is enclosed in parentheses. This statement only indicates
that the parentheses are not required for the assignment indicated by
the auto-increment or decrement functionality.

> > 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.

In C, the auto-increment operator is not atomic. In fact, the results of
the assignment are only guaranteed to be consistent at sequence points,
like after many statements complete. Historically, it has appeared
atomic because it was frequently implemented by a CISC instruction that
did the increment as a side-effect. The language does not guarantee that
this occurs, however.

> 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
> >
> >

Again, because all of these comments are on the original wording, the
voting is still open on the addition to the standard.

Karen



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