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
|