Floating Point Greater Than 32 bits, What are my Options?

Drone

Hello All,

I need at least 40 bit floating point multiply and divide. The calling application is small and speed isn't a big factor (10's of milliseconds per floating point multiply or divide should be OK). I've used the floating point objects from the object exchange but they're all limited to 32 bits. I've asked Imagecraft if their C-compiler for the propeller does more than 32 bit float - nope, and seemingly no plan for it.

Any suggestions before I decide whether to re-invent the wheel, or move to another processor? Ideally, I wish for arbitrary-precision floating point for the prop.

Thanks for any suggestions... David

Mike Green

You could certainly do arbitrary precision floating point arithmetic in Spin since speed isn't a problem and the built-in multiply will give you a 64 bit product. There's not a lot of call for floating point in the types of applications suitable for the Propeller and the existing floating point package is more than adequate for most of that. You might consider arbitrary precision fixed point arithmetic. It's simpler and faster and may be adequate for your application.

Ale

Fi you do not care about being binary, you can use my BCD library that is described in the MATH page at propellerwiki. It is a 12 digit (always 12) package. It could be extended with a little bit of work to 15 digits.
If you only need add/sub mul and div for 32 or more significant digits... maybe you can implement some (it is not that difficult) double precision routines. I think it is really fun, and I planned to do it anyways so if you do not need it for yesterday... I can do it for you. Just let me know if any of this helps you.

Drone

Hi Ale & Mike,.

Ale, I've studied the application a bit further and I think I can get away with 38 or 39 bits, so perhaps your BCD lib with 12 digits can handle this(?) Do you have your BCD arithmetic routines rolled up into an object? If so, where may I download it (it's not in ObEx)? If not, I take it the code on the Wiki is stable enough to scrape of the page?

The application is calculating optimal divider values used to program a Silicon Laboratories Si570 programmable clock generator with sub Hertz resolution.

Most would think a 32-bit heavy-lifter like the Propeller would be able to handle double-precision with ease, I did at-first. An acquaintance has successfully implemented an identical application with a little Freescale 8-bit HCS08 architecture micro-controller (MC9S08QG8) programmed in C. No problem with 64 bit precision. I was very disappointed with Imagecraft dismissing out-of-hand double precision in their C-compiler. This is one of the rare times when I wonder if the prop is the right part for the job.

Maybe I'll have a crack at arbitrary precision arithmetic. It should be pretty simple to bang out a brute force Euclidean algorithm for divide. Multiply seems even simpler.

Thanks, David

Ale

There is a download at the end of the page with all routines. You will have to add a bit of spin wrapper if you will call it from spin (in my case, I use it directly as it is from assembler). I use it to calculate frequency words for a DDS. It works super, mostly addition and multiplication, but all routines work. I do not know what for conversion you may need/use. Go ahead and use it, it is LGPL, so no problem to bundle it with your code.

For double precision, I'm working now in the addition and subtraction, they are done, I'm testing comparing the results with my pc . After I'm done with that I'll add multiplication and division.

Well, there are some libraries for the HC08, being a descendant of the 6800 those exists since the 70s . The prop maybe overkill.

Drone

Hi Ale,

I finally saw the link at the bottom of the wiki page for the BCD math code, thanks. Ya, the prop is overkill for just driving the Si570 but in the end the prop will do more. Plus I would like to bring the Si570 to the prop as drivers for most every other mainstream processor seem to have been done already. (I suspect lack of precision above 32 bits with the prop is the reason.)

Arbitrary precision might be a better solution then fixed 64 bit, especially with divide. I'm no expert but at first glance arbitrary precision divide might even be easier to code. Plus, arbitrary precision would allow users to choose the precision they require, this may (or may-not) reduce the memory footprint when full 64 bit precision isn't needed (hmmm....). I look forward to seeing what you come up with. Thanks for your time and effort...

Regards, David

Ale

Drone: I have already addition, subtraction and multiplication. The mul takes around 2000 cycles. Addition can take as little as 100 cycles. They only check for NaNs/infinity but do not distinguish between them and all the possible combinations (that would require as much space as the whole multiplication routine). So far I'm at 250 longs with some support routines. There is no fp->int or string conversion... that is another story. I'll add division, and post it in the Math page and of course I'll let you know.

Ale

Drone: I have the four basic functions sort of IEEE754 compliant, as stated above. The question is what conversion routines do you need ?, do you need sqrt ?. There is not that much place left (half a cog) so not everything can be fit, but maybe with a help from spin something can be done. I'll add sqrt anyways (I'll program it, and it can be later removed).