Subject: Re: bump operators. How do we size the '1'
From: Stuart Sutherland (stuart@sutherland-hdl.com)
Date: Tue Jul 31 2001 - 12:56:20 PDT
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?
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 - 12:59:24 PDT