Re: UM* (multiplication) bug in common 6502 Forths
Posted: Thu Dec 27, 2012 2:26 pm
Garth/Ed:
Thanks very much for the replies. I can assume then that an unsigned mixed precision instruction/subroutine/primitive might be helpful to implement.
I typically work with fixed point signal processing algorithms. As such, I hardly ever use the lower half of a signed/unsigned multiplication product. The results that I'm after are almost always contained in the upper half of the product.
Since I tend to build these functions in custom hardware, I tend to forget about the fact that all HLL languages have no support for multiplication in the sense that I require. Even on the MIPS architecture, most languages return the lower half of the product even though a dedicated register is provided that holds the upper half of the product.
Perhaps I've never properly used casting to get the proper product. Invariably to make the code work properly in an HLL, I've always had to cast the multiplier and multiplicand into next larger integer size. This tends to generate a bigger product which is not directly supported which generates library calls, etc. etc.
(-0.5)*(-0.5) = 0.25 <=> (-128/256)*(-128/256) = (16384/65536)
Thanks very much for the replies. I can assume then that an unsigned mixed precision instruction/subroutine/primitive might be helpful to implement.
I typically work with fixed point signal processing algorithms. As such, I hardly ever use the lower half of a signed/unsigned multiplication product. The results that I'm after are almost always contained in the upper half of the product.
Since I tend to build these functions in custom hardware, I tend to forget about the fact that all HLL languages have no support for multiplication in the sense that I require. Even on the MIPS architecture, most languages return the lower half of the product even though a dedicated register is provided that holds the upper half of the product.
Perhaps I've never properly used casting to get the proper product. Invariably to make the code work properly in an HLL, I've always had to cast the multiplier and multiplicand into next larger integer size. This tends to generate a bigger product which is not directly supported which generates library calls, etc. etc.
(-0.5)*(-0.5) = 0.25 <=> (-128/256)*(-128/256) = (16384/65536)