Subject: Re: bump operators. How do we size the '1'
From: John Sanguinetti (jws@forteds.com)
Date: Wed Aug 01 2001 - 11:11:05 PDT
This discussion is getting to be longer than it is worth.
At 7:16 PM -0700 7/31/01, Stuart Sutherland wrote:
>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.
If ++a is replaced by (a=a+1), then it still doesn't matter what size
the constant is, because the size is governed by a (the left hand
side context). If it overflowed, it overflowed.
>
>Hence the need for V++ to explicitly define the width of the ++ and
>-- operations.
>
>Stu
>
The proper explicit definition of the width of the operators is that
they are self-determined, just like << and >>.
This archive was generated by hypermail 2b28 : Wed Aug 01 2001 - 11:12:54 PDT