MicroMega's uFPU

[victorf]

The MicroMega Corp's uMFPU is a floating point co-processor. The device can be seen here:
www.MicroMegaCorp.com
and are available at Sparkfun.com
www.sparkfun.com

Has anyone explored the use of one of these puppies in the ZX environment? Is it a feasible addition to a math intensive project on a ZX-24?

Any enlightenment will be appreciated.

Vic

[spamiam]

I have seen this before. I do not feel that it adds much to the functionality of the ZBasic platforms, which already support 32 bit floating point.

Wonder if it adds ANY speed for the math tasks. It might be faster if you use all 5 of its registers, and/or do repetetive calculations using an accumulator in the FPU.

But the type of FP coprocessor I would be looking for is the kind that supports 80 bit floats, and does trancendental operations too.

I once did ASM programming of the Intel 286/287 combo. It was quite nice. I have never had to do the same for later Intel chips, but I understand that the pentium lines have one on-board.

The 287 did not have registers as such, but had a stack. Some (all?)operations could be done using the top of the stack and any element below it.

At the time I was pretty good with RPN on HP calculators, and I really liked that technique. The 287 essentially used RPN.

So, unless a coprocessor offers added accuracy over the ZBasic native math, I see little benefit.......

-Tony

[stevech]

It's a PIC with FP aboard, as I recall. I don't know about the ZBasic VM, but the FP library for GCC is in pretty efficient assembly code.

I wonder if the time overhead of moving the operands and result back and forth between chips largely offsets its benefit. It's serial data, not dual-ported memory. In some very odd cases, freeing up the AVR to compute whilst the FPU runs in parallel may make sense. Seems unliikely to me.

[spamiam]

[dkinzer]

I did some quick tests of ZBasic FP operation times using the values pi and e. A multiplication took about 50uS, division 77uS, square root 175uS and log10 350uS. These times include reading the operand value(s) and storing the result.

As far as I can tell, the uMFPU requires sending 6 bytes to the device for each 32-bit operand plus 2 bytes for the operation command. To read the result, 2 bytes need to be sent and 4 bytes read. The time for sending and receiving alone (using the faster SPI interface) for a binary operation will be 20 bytes * 8 bits/byte * 250nS/bit = 40uS. According to the datasheet, there is an additional 15uS "read delay period" that must be observed between sending the read command and beginning to read the data. This brings the total to 55uS. There may be (probably is) an additional delay between the sending of the operation command and the operation being completed. I couldn't find any information on the operation times.

Notwithstanding the foregoing, the ability to store a "program" in the device might be useful for exploiting the benefits of parallel processing. This could work well if you had some complex computations involving a few operands - just send the operands, instruct it to begin and go do other things while it computes the result.

[stevech]

maybe some sort of multiply-and-accumulate function is where that parallelism helps. But this kind of math is not normally done on a little 8 bit micro, I speculate - except in a low budget University lab, eh?

Pretty good numbers for FP in the VM!

When dinosaurs roamed the earth, I remember a project we were doing, using a Data General Nova 800 (16 bit, core) and we bought a hugely expensive FP box for it. Like 6U rack space. It wasn't much faster! Ah, and our 5MB hard disk was a ga-zillion dollars too.

[mikep]

[spamiam]

200+G FLOP.... Seems quite good. What does a 3GHz P4 do? Less than 3G FLOPS, I presume.

-T

[mikep]

[GTBecker]

[spamiam]

[victorf]

Tom,

Thanks for your views on the uFPU. I am seriously considering using it in my new ZBasic project. It will need some math beyond simple multiplication division stuff. I will go the SPI route.

Since you have a bit of experience with the FPU, do you have any code to share?

Any enlightenment will be appreciated.

Vic

[GTBecker]

[GTBecker]

Vic, I haven't gotten to 1+1=2.0000000001, yet. It is encouraging, though, to see

{RESET}
>V
uM-FPU V3.0.3, I2C:00 29.48 MHz

from the onboard debug monitor. I'll probably have the equivalent of "Hello World" tonight.

[mikep]