[Coco] long math subroutine module?

[John Kent]

I did post a couple of FPGA cores that did 32 bit integer hardware 
multiply & divide to one of the mailing lists I'm on. You can scale them 
down for 16 bits, or just truncate the 32 bit or 64 bit result, and 
maybe sign extend the inputs.

5 bytes is an odd size for a float. IEEE754 uses 4 bytes as I recall and 
8 bytes for a double. Add and subtract aren't hard except you have to 
de-normalize the inputs and normalize the output. Multiply and divide 
aren't so hard to de-normalize and normalize as all you have to do is 
add or subtract the exponents.

IEEE754 floating point numbers normally have the (hidden) MSBit set. To 
do a normalization or de-normalization in one cycle needs a reasonable 
size barrel shifter which uses a fair bit of logic. A barrel shifter is 
essentially a big multiplexer that can shift the whole mantissa, an 
arbitrary number of bits.The alternative is to shift it one bit per 
cycle, which is much slower but uses much less logic.

5 byte floats are not IEEE754 standard although it might be possible to 
scale the number of bits. The exponent on an IEEE754 float or double is 
offset by some constant.

An FPU might be implementable in the CoCo3FPGA, or even on it's own FPGA 
board. There are a few low cost FPGA boards with just a single FPGA, 
clock and configuration flash that could be interfaced to a CoCo if it 
could be mapped into memory.

John.

On 13/04/2012 2:02 PM, gene heskett wrote:
> On Friday, April 13, 2012 12:01:18 AM Willard Goosey did opine:
>
>> On Wed, Apr 11, 2012 at 11:31:56PM -0400, gene heskett wrote:
>>> So far as I have heard about, no.  I believe the real problem is the
>>> size of an int in basic09 is 16 bits&  even a real is only 5 bytes
>>> including the exponent.
>> Exactly.  Now I'm really wondering why nobody's written such a thing.
>>
>>> I believe if you need that in long or double, you'll need to write it
>>> in C and use the trig.l to get those functions where the accuracy
>>> only gets fuzzy about 16 or 17 digits out.  They work well until the
>>> julian calender hits zero in the middle of 4713 BC.
>> That amuses me, because my reason for asking is that I want to
>> directly manipulate the real file-pointer returned by the system calls
>> via SYSCALL... If you're doing trig on a file pointer you're doing
>> something VERY strange! :-)
>>
>> Willard
> That wasn't the point.  The point was that the high precision double float
> operations for all this is in the trig.l library.
>
> Cheers, Gene

-- 
http://www.johnkent.com.au
http://members.optusnet.com.au/jekent