Subject:
|
Re: Some comments (long) (was: Something else is needed, I think...)
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Thu, 6 May 1999 17:58:04 GMT
|
Viewed:
|
1249 times
|
| |
|
|
Mark Tarrabain wrote in message <3730DE97.EFB3BF9A@lynx.bc.ca>...
> ...
> I do not believe that a compatible bytecode interpreter can feasibly
> have any floating point routines built into it. Fixed point would need
> to be used at the source code level. It's not that difficult to, at the
> source code level, use everything multiplied by some constant factor
> anyways. This also gives the flexibility of the user being able to use
> whatever precision they decide is appropriate for their particular
> application.
> ...
It is probably true that a floating-point library cannot (should not?) be
built into the firmware. It would probably be better for this to be
supported by the compiler(s). But this still implies that the bytecode
interpreter is actually capable of supporting the necessary atomic
operations upon which a useable floating or fixed-point library can be
built. Which brings me to my point...
I strongly disagree with the common assertion that you can simply revert
to a fixed-point representation under the current 16-bit firmware. I gave
up trying to do any sort of trigonometry because (PLEASE correct me if I'm
wrong) 16 bits are not enough to do even basic calculations in fixed point.
As far as I know, the standard firmware doesn't provide any access to the
overflow and carry bits that are set as the result of simple arithmetic
operations, nor do they allow access to the 32-bit result of a 16-bit
multiply, or the remainder portion of a divide operation. These limitations
make it virtually (?) impossible to do useful fixed-point calculations on
the RCX.
For example, suppose you use 12 bits for the integer portion and a measly
4 bits for the fractional component. This means that you can represent
signed numbers from +- 512 in increments of 1/16. If you multiply 32.0 *
32.0, you will overflow the variable and (because you cannot gain access to
the high word of the result) you cannot regain the lost bits. And the
situation is actually worse than that, because after such a multiply, you
must divide the result by 16 to put the decimal point (binary point?) back
where it belongs, so even multiplying 8.0 * 8.0 will run into overflow
problems, since the top 4 bits of the result are guaranteed to be zero (or
one if the result is negative) after the scale factor correction.
Even if you were to use one 16-bit variable for the whole component and
another for the fraction, you still overflow the variable when you multiply
256.0 * 256.0. And splitting your storage across two variables like this
dramatically increases the number of computations that must be performed in
order to emulate a single arithmetic operation, decreasing efficiency and
increasing code size.
Two firmware improvements would relieve this situation, IMHO. One would
be to support 32-bit integer variables to extend the useable range of simple
fixed-point calculations in user code. The other would be to support an
opcode which performs a combined multiply and divide without losing any bits
during the intermediate operations. (The MS Windows API function MulDiv()
does this.) The MULDIV opcode would take three 16-bit arguments, which I
will call A, B, and C. First, (A * B) is calculated as a 32-bit extended
value. (I don't know, but suspect that the H8 instruction set supports
this.) Then this value is divided by C, yielding a 16-bit result. This
would enable user code to implement fixed-point calculations over a much
larger numeric range without loss of precision or danger of overflow.
I don't know enough about the H8 (yet) to say whether these enhancements
are feasible. But I do know that they are necessary if that little yellow
brick is ever going to do all of the things I am trying to get it to do.
Let me close by saying that I applaud this effort to improve the RCX
firmware, and humbly offer my assistance.
|
|
Message has 1 Reply:
Message is in Reply To:
42 Messages in This Thread:
  
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
Active threads in Robotics
|
|
|
|
|
|
