Subject: Re: bump operators. How do we size the '1'
From: Michael McNamara (mac@verisity.com)
Date: Tue Jul 31 2001 - 18:14:17 PDT
Stuart Sutherland writes:
> As I recall, it was the synthesis vendors and not the simulator vendors
> that were concerned about all the different ways ++ and -- could be
> used. But synthesis requires style restrictions on a lot of constructs, so
> to me it was a lame excuse.
>
> I'm not sure the size of the expression is a non-issue, but I haven't
> thought it all the way through. Section 4.4.2 of draft 6 of the
> Verilog-2001 gives an example where MAYBE the size of a bump expression
> would be important:
>
> reg [15:0] a, b, answer; // 16-bit regs
> answer = (a + b) >> 1;
>
> The LRM uses this to show that because the operands within the parenthesis
> are 16 bits wide, the result is not what it would first appear to be,
> because there is no overflow in the math operation. The suggested fix in
> the LRM is to do (a + b + 0) to force a 32-bit addition result.
>
> If a bump operator were substituted in that example, what would the
> addition result size be?
>
> answer = (a++) >> 1; //is there an overflow?
> answer = (a++ + b) >> 1; //is there an overflow?
Actually, I am not at all interested in size here, but rather in what
does the code mean.
Given
main(){
int a, answer, b;
a = 1;
b = 2;
answer = (a++) >> 1;
printf("answer is %d a is %d\n", answer,a);
answer = (a++ + b) >> 1;
printf("answer is %d a is %d\n",answer,a);
}
You may be thinking that C would print
answer is 1 a is 2
answer is 2 a is 3
but instead it prints:
answer is 0 a is 2
answer is 2 a is 3
If it was coded as:
answer = (++a) >> 1;
printf("answer is %d a is %d\n", answer,a);
answer = (++a + b) >> 1;
printf("answer is %d a is %d\n",answer,a);
You would get:
answer is 1 a is 2
answer is 2 a is 3
That is because 'answer = (a++)' means assign 'a' to 'answer' and THEN
increment a after the assignment in complete.
>
> Now we have signed declarations and an arithmetic right-shift
> operator. The width of expression results affects these as well.
>
> Perhaps "self-determined" does answer all the width possibilities. Again,
> I haven't thought this through. I'm just throwing out some things to ponder.
>
>
> BTW, I don't like the term "bump operators" either. "Increment" and
> "decrement" are much more intuitive.
>
> Stu
>
>
> At 12:25 PM 7/31/2001, Clifford E. Cummings wrote:
> >At 07:23 PM 7/30/01 -0700, you wrote:
> > >>Page 21 - Anders: bump operators. How do we size the '1'. For example what
> > >>happens to the 1 the case of overflow. Statement needed in doc on the
> > >>"size" of the 1. Suggested wording: The resultant size of the operator is
> > >>the size of the operand.
> > >>Action - Stu to include wording in doc.
> > >>
> > >
> > >After thinking about this for more than 5 seconds, I don't believe
> > >there is an issue here. Contrary to what I said during the meeting,
> > >it doesn't really matter what size the constant one is, since the
> > >only natural interpretation is that auto-increment and auto-decrement
> > >(better terms than "bump operators") are self-determined. If a++
> > >means a = a + 1 the left context is a, so the size will be the size
> > >of a, regardless of what size the constant 1 is. This only needs an
> > >entry in the size table that says the result of auto-increment and
> > >auto-decrement is self-determined.
> > >
> > >John
> >
> >
> >I believe John is right.
> >
> >I believe the objection to i++ and its variants had more to do with the
> >fact that expressions could be used almost anywhere and the vendors were
> >not crazy about parsing an i++ expression that might be passed as a
> >function input, module input, etc. As users, we wanted the ++ and --
> >capabilities, especially in the header of a for-loop, but the vendors
> >prevailed in convincing us that this was too burdensome to implement.
> >
> >It is nice to see that Superlog was able to add the capability so easily.
> >
> >Regards - Cliff
> >
> >//*****************************************************************//
> >// Cliff Cummings Phone: 503-641-8446 //
> >// Sunburst Design, Inc. FAX: 503-641-8486 //
> >// 14314 SW Allen Blvd. E-mail: cliffc@sunburst-design.com //
> >// PMB 501 Web: www.sunburst-design.com //
> >// Beaverton, OR 97005 //
> >// //
> >// Expert Verilog, Synthesis and Verification Training //
> >//*****************************************************************//
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Stuart Sutherland Sutherland HDL Inc.
> stuart@sutherland-hdl.com 22805 SW 92nd Place
> phone: 503-692-0898 Tualatin, OR 97062
> www.sutherland-hdl.com
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
This archive was generated by hypermail 2b28 : Tue Jul 31 2001 - 18:15:20 PDT