um-FPU 32/64 coprocessor vs Propeller
Alex.Stanfield
Posts: 198
Has anyone used the micromega FPU coprocessors? I was reading the specs which seem impressive with all the additional functions. Then I saw the performance numbers for each operation...
In particular integer math have for example these numbers
LMUL 7.1 uS
LDIV ~20 uS
With a PASM routine: Doesn't it take less time to do integer multiplication/division?
What's your experience?
Alex
In particular integer math have for example these numbers
LMUL 7.1 uS
LDIV ~20 uS
With a PASM routine: Doesn't it take less time to do integer multiplication/division?
What's your experience?
Alex
Comments
IMO, the 64-bit version looks very interesting. With 64-bit math, it might be worth having to deal with the data transfer times.
I agree it looks great, my doubt is only related to speed. I haven't seen the particular example, but isn't an equation just a script of operations that get sequentially executed? In that case wouldn't it be cheaper to launch a cog dedicated to equation calculation?
Alex
At $40 the espruino isn't cheap, but it does have the advantage of code portability, so it has that going for it.
He has links to other boards that should work. e.g. STM32VLDISCOVERY for $10 and of course the chip alone would be cheaper. I would buy one of the official boards for ease of getting started and to support them, but it's not necessary.
A question I would ask is how well verified is the math that's in the espruino? One could imagine that micromega might do a better job of verification since it's their main reason for existing. Take a look through the espruino forums and see what issues are being reported, how compliant it is with javascript, etcetera.
I had used uM-FPUv3.1 to calculate inverse-kinematics-calculation for delta-robot in 2012 Oct.
I had wrote inverse-kinematics-calculation to eeprom inside uM-FPUv3.1(PIC).
PropForth send (x,y,z) to uM-FPUv3.1. And uM-FPUv3.1 return values(sv1,sv2,sv3) of pulse-width for 3 servos.
http://youtu.be/fhyy_JcLuFQ
I use an STM32F4 Discovery with the Espruino software, only 15 dollars.
http://www.cnx-software.com/2011/10/28/st-micro-15-usd-stm32f4-discovery-cortex-m-development-kit/
The OLIMEX boards are cheap. Or just use the chip on your own boards.
KeithE, Strange thing to worry about.
The STM32 chips have floating point in hardware. If any bugs turn up in the maths in JavaScript I'm sure Gordon Williams will get them fixed pretty quickly. I see no reason why this software should be suspected of being more buggy than whatever they programmed into the PIC24 for UN-FPU.
Gordon has done an amazing job creating the JavaScript interpreter. I would not be surprised if there were odd corner cases of the JS language that are broken. Most would admit that JS itself has a lot of "broken" features by design (Thank you MicroSoft). Not to worry, again Gordon has been very good ant getting things fixed. And heck, don't do weird stuff.
Alex.Stanfield, why not just do the floating point on the Propeller with the F32 object?
I may do that after all. After seeing the speed values for each operation...
Alex
A little browsing of the forums shows these recent math related (?) bugs. Looks like 2 out of 3 are closed, but to me it indicates how new and potentially buggy this is. It doesn't mean it shouldn't be used, but I would look into the test suite. It looks like it's missing coverage.
http://forum.espruino.com/conversations/1065/
http://forum.espruino.com/conversations/1004/
http://forum.espruino.com/conversations/902/
How would you interface between a propeller and espruino for this application? I would think that you want to send the floats in binary format.
You seem determined to throw doubt on the Espruino.
Perhaps you remember the the Intel Pentium "FOOF" bug. Google it if not.
Perhaps you remember that the Intel 286 when asked to multiply by an immediate integer value that happened to be negative always gave the wrong result.
Everything has bugs some time.
Now, whatever program you write I'm sure you are going to test it. Right? If there is a bug Gordon will fix it. No way.
Send it commands in ASCII over a serial link.
At that point you find out it's quicker to do the calcs in the Propeller with F32. Or move the bulk of the intelligence to the Espruino and let the Prop take care of the IO.
FYI - I've worked with the people who designed the Weitek and NexGen FPUs.
The "faster, easier, cheaper" thing was all in comparison to bolting the proposed FPU onto a Propeller. I suspect that is just a naff kludge of an idea.
By the way, what application? None has been mentioned here.