Re: [myhdl-list] intbv.signed()
Brought to you by:
jandecaluwe
From: Günter D. <dan...@we...> - 2008-07-30 21:28:29
|
Jan Decaluwe wrote: ... > > I would go for an integer to start with. That is what MyHDL does now for > many operators. It is more efficient than constructing intbv's (although > I dont' know how much more) and seems sufficient in many cases. I was thinking about the processing of the signed() function and basically need to do a categorization when the value of an intbv instance is considered unsigned. In that case the the signed() function will change the value based on the msb bit, which is considered the sign bit. In the other case the value is considered signed and the function will return it just as is. When considering intbv instances there are several combinations of min/max values possible. The following diagram shows them: ----+----+----+----+----+----+----+---- -3 -2 -1 0 1 2 3 1 min max 2 min max 3 min max 4 min max 5 min max 6 min max 7 min max 8 neither min nor max is set 9 only max is set 10 only min is set The horizontal line shows a number range from -3 to 3. Then each line shows different cases of min/max values of an intbv instance. As an example, in the first case min=0 and max > 0. The second case min > 0 and max > min, etc. From all those cases I think only two cases, namely 1 and 2, are where the value is considered unsigned and the signed() function will return a modified value. In all other cases either there is no range specified or the min value is < 0, which makes that intbv instance already considered signed and the signed() function will just return the value as is. So the test will be for min >= 0 and _nrbits > 0. That case will classify the intbv instance as unsigned and the signed() function will return the value as signed, with the sign being determined based on the msb. The msb is bit # _nrbits-1. Note that case #10 (only min is set) could fulfill the requirement min >=0, but as no max is set, _nrbits is 0 and hence the second test will not be True. Guenter |