Subject: Re: bump operators. How do we size the '1'
From: Stuart Sutherland (stuart@sutherland-hdl.com)
Date: Tue Jul 31 2001 - 19:16:50 PDT
The example was hastily thrown together, and not meant to be useful in
representing real hardware. I agree that it would have made a little more
sense to have used a prefix ++ instead of a postfix ++ in my hastily
constructed example. But that isn't the point. The point is how many bits
wide is the a++ or ++a operation in Verilog, not in C.
Just so no one has search below, the original example (straight from the
1364 LRM) was:
reg [15:0] a, b, answer; // 16-bit regs
answer = (a + b) >> 1;
The issue is that if we use Verilog-1995 rules, the (a + b) from the
example will do 16 bit math, with no overflow, and a right shift will
always shift in a zero instead of the overflow. On the other hand, (a + b
+ 0) will do at least 32-bit math, because the unsized 0 defaults to "at
least 32 bits wide". The overflow of a + b will fall into the 17th bit,
and the right shift will shift in the overflow value.
So how does the ++ operator affect the size of the operation? is (++a + b)
a 16-bit operation with no overflow, a 17-bit operation, a 32-bit operation
or a 64-bit operation? If one were to assume that "++a" is the same as
"a=a+1", then the expression (++a + b) will be at least a 32-bit operation,
because the unsized 1 of a=a+1 defaults to at least 32 bits wide. On the
other hand, if "++a" is equivalent to "a=a+1'b1", then (++a + b) will do
16-bit math, with no overflow.
Hence the need for V++ to explicitly define the width of the ++ and --
operations.
Stu
At 06:14 PM 7/31/2001, Michael McNamara wrote:
>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
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> >
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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 - 19:16:51 PDT