A Floating Point Problem

deSilva

I successfully ran FloatDemo using (the slow) FloatMath and FloatString.

I then changed "FloatMath" to "Float32" in FloatDemo.

This worked well, but FloatString still used FloatMath

I then changed "FloatMath" to "Float32" in FloatString as well.

Bingo!

I debugged for half an hour without success - what can be the problem??
It seems that FloatString.Setup() never returns (endless repeat loop)...

Mike Green

Float32 has a start routine that must be called before otherwise using it (see the documentation for Float32). If you don't call it first, the other routines will hang which sounds like what's happening.

deSilva

Good point, but I did it (though didn't mention it), otherwise already my first attempt would have failed.
No, Math32 works fine, but MathString does not!

deSilva

The story turned out as follows... But no, I shall repeat what my problem was first:
I have a FloatingPoint program that was using Float32 AND FloatString.

FloatString on the other hand uses FloatMath, which is inefficient and useless memory spending, so I changed the OBJ in FloatString also to "Math32".

This however did not work!

It was not clear to me in the beginning, but the entry of
F : "Float32"
in OBJ - of course! - instantiates a new copy of Float32!

But how can you avoid this???? I want FloatString to use the same instance of Float32 as the main program. I have found nothing in the Spin manual to allow this!

The work around was - of course - to copy FloatString into Main, but this is awkward and not at all modular.

Any ideas?

Post Edited (deSilva) : 6/24/2007 8:45:07 PM GMT

Mike Green

Alas, there is no easy way to do that.· There are some workarounds.· One is to have the main program allocate a work area that gets passed to the calls to the float package whether they're from the main program or indirectly via the FloatString package.· Another option is to modify the float package to use a DAT section for its local workarea.· The Propeller Tool does eliminate multiple instances of the code and the DAT space·so the only thing that is duplicated is the VAR area.· If there's no VAR area, there's only one instance no matter how many times the object is declared in OBJ statements.· With the first option, you can have precisely how many instances you want and have them where you want them.· It costs a bit in overhead since the indirect workarea references are less efficient than the direct VAR references.· The second option doesn't let you have multiple instances without duplicating the source code for the object.· I think the compiler still will eliminate duplicate code spaces that are identical in binary.




Post Edited (Mike Green) : 6/24/2007 8:08:46 PM GMT

deSilva

This looks like a major loophole in the language design!

Careful design of moduls can help, as Mike pointed out: In this special case it seems that the culprits were the object variables "command" and "cmdReturn" which should rather have been (static) class variables in the data section. Maybe I can provide a fix but I will first make some changes to Math 32, allowing for parallel work on small vectors and complex numbers as well as keeping an unpacked format for chain calculations.

You probably guessed it: The Mandelbrot Set, but is is still so slow......