FloatMathPlugin status?
Locked
 
|
As part of my "let's see what I haven't got around to yet" attack on the VM, I tried making the FloatMethPlugin on RISC OS. I got bitten by the __LITTLE_ENDIAN define requirement, and the very odd seeming problem with isnan() but eventually go a plugin built. When trying to use the TestRunner to see it if worked I was a little startled to find it blew my VM out of the water without so much as a by-your-leave.
Googling doesn't bring up much that seems useful so I'm forced to throw myself on the collective memory of listers. Am I wasting my time here - is it actually in use or about to become useful for general Squeak operations? Can anyone remember any implementation issues that might help me fix it? Why was isnan() an issue? Why do lions? tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Hardware: The parts of a computer system that can be kicked. |
|
|
On Sun, Feb 17, 2013 at 09:31:36PM -0800, tim Rowledge wrote:
> As part of my "let's see what I haven't got around to yet" attack on the VM, I tried making the FloatMethPlugin on RISC OS. I got bitten by the __LITTLE_ENDIAN define requirement, and the very odd seeming problem with isnan() but eventually go a plugin built. When trying to use the TestRunner to see it if worked I was a little startled to find it blew my VM out of the water without so much as a by-your-leave. > > Googling doesn't bring up much that seems useful so I'm forced to throw myself on the collective memory of listers. Am I wasting my time here - is it actually in use or about to become useful for general Squeak operations? Can anyone remember any implementation issues that might help me fix it? Why was isnan() an issue? Why do lions? > It is compiled as in internal plugin in the unix VMs. I don't recall any changes to this plugin or the support code. One related note - in Cog (image format 6505), the double precision floats are stored in platform native word order, so on a little-ender the high and low order words of a double are reversed compared to the traditional interpreter (6504 or 6502) formats. But I don't think that there is any effect on the support code, and anyway the interpreter VM swaps them all back to expected order at image load time. Dave |
|
|
In reply to this post by timrowledge
On 2013-02-18, at 06:31, tim Rowledge <[hidden email]> wrote: > As part of my "let's see what I haven't got around to yet" attack on the VM, I tried making the FloatMethPlugin on RISC OS. I got bitten by the __LITTLE_ENDIAN define requirement, and the very odd seeming problem with isnan() but eventually go a plugin built. When trying to use the TestRunner to see it if worked I was a little startled to find it blew my VM out of the water without so much as a by-your-leave. > > Googling doesn't bring up much that seems useful so I'm forced to throw myself on the collective memory of listers. Am I wasting my time here - is it actually in use or about to become useful for general Squeak operations? Can anyone remember any implementation issues that might help me fix it? Why was isnan() an issue? Why do lions? This is used in Croquet. It ensures bit-identical float operations across all platforms. That's what the tests, err, test. Otherwise, different clients would get out of sync. - Bert - |
|
|
FloatMathPlugin uses fdlibm library.
fdlibm library relies on pointer aliasing, which is Undefined Behavior according to C99 standard With -O2 optimization, gcc does not produce correct code with such pointer aliasing... A well known workaround is to compile fdlibm with -fno-strict-aliasing flag. It might be the same for RiscOS C compiler... Don't know if it's enough though, or if there is further UB... Nicolas 2013/2/18 Bert Freudenberg <[hidden email]>: > > On 2013-02-18, at 06:31, tim Rowledge <[hidden email]> wrote: > >> As part of my "let's see what I haven't got around to yet" attack on the VM, I tried making the FloatMethPlugin on RISC OS. I got bitten by the __LITTLE_ENDIAN define requirement, and the very odd seeming problem with isnan() but eventually go a plugin built. When trying to use the TestRunner to see it if worked I was a little startled to find it blew my VM out of the water without so much as a by-your-leave. >> >> Googling doesn't bring up much that seems useful so I'm forced to throw myself on the collective memory of listers. Am I wasting my time here - is it actually in use or about to become useful for general Squeak operations? Can anyone remember any implementation issues that might help me fix it? Why was isnan() an issue? Why do lions? > > > This is used in Croquet. It ensures bit-identical float operations across all platforms. That's what the tests, err, test. Otherwise, different clients would get out of sync. > > - Bert - > > > |
|
|
On 18-02-2013, at 10:14 AM, Nicolas Cellier <[hidden email]> wrote: > FloatMathPlugin uses fdlibm library. > fdlibm library relies on pointer aliasing, which is Undefined Behavior > according to C99 standard Oh, well that sounds like it might cause fun. > With -O2 optimization, gcc does not produce correct code with such > pointer aliasing... > A well known workaround is to compile fdlibm with -fno-strict-aliasing flag. Wonder if that has any effect on the NorCroft RISC OS compiler. I'll give it a try. It looked a bit odd to me that the generated plugin wants to rely on isnan() being a pretty specific routine in the fdlibm code and yet that is a pretty general macro defined in the basic C libraries. There is clearly an attempt in the .h file to work around that but surely you're asking for trouble by mixing two libraries with evidently differing ideas of what is the way to do things? I think I'll try changing the isnan to something else so it can't clash and see what happens. If you see a big plume of smoke from the north west you'll know it didn't work... tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful random insult:- One too many lights out in his Christmas tree. |
|
|
2013/2/18 tim Rowledge <[hidden email]>:
> > On 18-02-2013, at 10:14 AM, Nicolas Cellier <[hidden email]> wrote: > >> FloatMathPlugin uses fdlibm library. >> fdlibm library relies on pointer aliasing, which is Undefined Behavior >> according to C99 standard > > Oh, well that sounds like it might cause fun. > >> With -O2 optimization, gcc does not produce correct code with such >> pointer aliasing... >> A well known workaround is to compile fdlibm with -fno-strict-aliasing flag. > > Wonder if that has any effect on the NorCroft RISC OS compiler. I'll give it a try. > > It looked a bit odd to me that the generated plugin wants to rely on isnan() being a pretty specific routine in the fdlibm code and yet that is a pretty general macro defined in the basic C libraries. There is clearly an attempt in the .h file to work around that but surely you're asking for trouble by mixing two libraries with evidently differing ideas of what is the way to do things? > AFAIK, fdlibm was supposed to provide a whole libm replacement. What can happen when mixing functions from the two libraries is left to adventurous explorators. http://www.netlib.org/fdlibm/readme suggests you might try it though... If this does not work, I don't know how difficult it is on RiscOS to avoid linking to standard functions usually found in libm. As I understand it, the whole library seems aggregated in a big SharedUnixLibrary (http://www.riscos.info/index.php/SharedUnixLibrary). Nicolas > I think I'll try changing the isnan to something else so it can't clash and see what happens. If you see a big plume of smoke from the north west you'll know it didn't work... > > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > Useful random insult:- One too many lights out in his Christmas tree. > > > |
|
|
2013/2/18 Nicolas Cellier <[hidden email]>:
> 2013/2/18 tim Rowledge <[hidden email]>: >> >> On 18-02-2013, at 10:14 AM, Nicolas Cellier <[hidden email]> wrote: >> >>> FloatMathPlugin uses fdlibm library. >>> fdlibm library relies on pointer aliasing, which is Undefined Behavior >>> according to C99 standard >> >> Oh, well that sounds like it might cause fun. >> >>> With -O2 optimization, gcc does not produce correct code with such >>> pointer aliasing... >>> A well known workaround is to compile fdlibm with -fno-strict-aliasing flag. >> >> Wonder if that has any effect on the NorCroft RISC OS compiler. I'll give it a try. >> >> It looked a bit odd to me that the generated plugin wants to rely on isnan() being a pretty specific routine in the fdlibm code and yet that is a pretty general macro defined in the basic C libraries. There is clearly an attempt in the .h file to work around that but surely you're asking for trouble by mixing two libraries with evidently differing ideas of what is the way to do things? >> > > AFAIK, fdlibm was supposed to provide a whole libm replacement. > What can happen when mixing functions from the two libraries is left > to adventurous explorators. > http://www.netlib.org/fdlibm/readme suggests you might try it though... > > If this does not work, I don't know how difficult it is on RiscOS to > avoid linking to standard functions usually found in libm. > As I understand it, the whole library seems aggregated in a big > SharedUnixLibrary > (http://www.riscos.info/index.php/SharedUnixLibrary). > Argh, wrong link, it would rather be http://www.riscos.info/index.php/Shared_C_Library > Nicolas > >> I think I'll try changing the isnan to something else so it can't clash and see what happens. If you see a big plume of smoke from the north west you'll know it didn't work... >> >> tim >> -- >> tim Rowledge; [hidden email]; http://www.rowledge.org/tim >> Useful random insult:- One too many lights out in his Christmas tree. >> >> >> |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |