I want to follow-up on my previous discussion on the fixed point with
a few observations and more suggestions. Initially, I had
misunderstood the meaning of the [x,y] precision format used by the
Ptolemy fixed-point infrastructure by assuming that this format did
not include a bit for the sign (I would have saved a lot of time had I
read the Precision class file documentation more carefully). The
bit-width specification in Precision assumes that a bit dedicated for
the sign and the arithmetic operations perform "signed" arithmetic
correctly with this definition.
While this appears to be working well, I am running into troubles when
I try to model unsigned arithmetic operations. Much of what I do
involves digital hardware circuits where unsigned arithmetic is very
common. I have been able to model much of the unsigned arithmetic
using the existing twos complement signed format supported by the
current code. However, I am having a number of problems when
rounding/truncating unsigned numbers using the existing code and
keeping track of the "extra" bit associated with the sign.
I would like to suggest modifying fixed point infrastructure to
support both signed and unsigned number formats naturally. While more
code would be required, I believe supporting both signed and unsigned
within the existing classes would be natural and relatively
straightforward. Details of my proposal are listed below.
Any suggestions on my proposal?
---------------------------------------------------------------
The current Precision class defines the fixed point precision using
two arguments, [x/y] where x specifies the total number of bits and y
specifies the number of integer valued bits. In this format, one of
the bits is assumed to be the sign bit.
[8/7]
Max value = 127 (01111111)
Min value = -128 (10000000)
I propose that we add another field in the precision specification
that allows for unsigned values. For example, such a specificatoin
could be [x/y/z] where x is used for the total number of bits, y is
used to specify the number of integer bits, and z is used to specify
the sign bit (z=0 indicates unsigned number and x=1 indicates a signed
number). Here are some examples of numbers in this new format:
[8/7/1]
Max value = 127 (01111111)
Min value = -128 (10000000)
Epsilon = 1
[8/7/0]
Max value = 63.5 (11111111)
Min value = 0 (000000000)
Epsilon = 0.5
[8/8/0]
Max value = 255 (11111111)
Min value = 0 (00000000)
Epsilon = 1
[8/8/1]
Max value = 254 (01111111 x 2 = 011111110)
Min value = -256 (10000000 x 2 = 100000000)
Epsilon = 2
Necessary Changes:
Precision.java
- support added representation for unsigned numbers
- Text format for specifying signed/unsigned behavior
- Field to represent signed/unsigned behavior
- Accessor method to determine signed/unsigned behavior
- Modification of all methods to correctly represent both unsigned
and signed numbers.
- backwards compatibility for signed only formats
(specification in old format creates a "signed" number)
Quantization.java
- This class assumes a sign bit. Modify the class to
query the unsigned/signed behavior to respond correctly
FixPoint.java (* this would involve the most work)
- Modification of all arithmetic functions to handle unsigned
arithmetic
- Produce a fixed value with the correct signed/signed
Operand A Operand B Result
unsigned unsigned unsigned
unsigned signed signed
signed unsigned signed
signed signed signed
- Modification of quantize method
Overflow.java
- Handle unsigned overflow
Rounding.java
- Handle unsigned rounding
No changes to:
FixType, FixToken, FixPointQuantization
--
Michael J. Wirthlin
Associate Professor
Electrical and Computer Engineering Voice: (801) 422-7601
Brigham Young University Fax: (801) 422-0201
459 Clyde Building Email: [EMAIL PROTECTED]
Provo, UT 84602 www.ee.byu.edu/faculty/wirthlin
----------------------------------------------------------------------------
Posted to the ptolemy-hackers mailing list. Please send administrative
mail for this list to: [EMAIL PROTECTED]
