Floating Point troubles in RPi 1.9.0-Alpha-gcc4
altosack
Posts: 132
in Propeller 1
If I include simpletools in my library path, I get conflicts between libsimpletools.a(fpucog.o) and libgcc.a(_loadfloat.o) for all of my float functions (___addsf3, ___subsf3, etc.). So... I comment out the line that includes simpletools in my library path, and it is able to compile. The only Simple Library functions I use are terminal output for debugging, which still works with only libsimpletext.a and not libsimpletools.a.
However, during run-time, it seems that the float functions do not work; I seem to get valid floating point numbers, but they are way off. For example, I get 278 when it should be 5760, 283 for 57600, 290 for 576000, etc. I pared it down to the following code:
The last time this code was working (for sure) was when I was compiling it on linux-x64; I don't think anything has changed since then, but unfortunately, my main linux machine is temporarily out of commission, so I can't verify that. If I go back to Rpi gcc 0.9.46, I get a segfault in gas (after changing .pasm to .cog_ram; ugh !) on the first file, so I did not pursue that further.
As an aside, the current propeller-load in 1.9.0-Alpha-gcc4 (downloaded 17 Dec 2015) doesn't recognize ttyAMA0; I have to use an older version.
Any ideas ?
However, during run-time, it seems that the float functions do not work; I seem to get valid floating point numbers, but they are way off. For example, I get 278 when it should be 5760, 283 for 57600, 290 for 576000, etc. I pared it down to the following code:
parseVolts(57.60, LEDmbx.displayString);
...
void parseVolts(float fnum, char *string) {
int inum;
inum = (int) (fnum * 100.0);
// inum = 5760;
...
}
If I inject "inum = 5760" (commented out in the above code), it displays correctly, but if I ask it to multiply a floating point immediate by 100 and convert it to an integer (the original code was of course a bit more involved before I pared it down), I get the values I stated above, not what they should be.The last time this code was working (for sure) was when I was compiling it on linux-x64; I don't think anything has changed since then, but unfortunately, my main linux machine is temporarily out of commission, so I can't verify that. If I go back to Rpi gcc 0.9.46, I get a segfault in gas (after changing .pasm to .cog_ram; ugh !) on the first file, so I did not pursue that further.
As an aside, the current propeller-load in 1.9.0-Alpha-gcc4 (downloaded 17 Dec 2015) doesn't recognize ttyAMA0; I have to use an older version.
Any ideas ?
Comments
Sorry I didn't post the whole project, but I thought that would obfuscate more than clarify. The snippet I have has no prior inputs, and the outputs go to a 7-segment display. When I put in the integer assignment statement as above, it works fine.
Maybe we could start at the top. Do you know why I'm getting the conflict between libsimpletools.a and libgcc.a ?
I'm using SimpleLib from the SimpleIDE release (I guess it's 0.9.46); I assume there's no newer version of this that needs to go with propgcc-1.9.0 ? It was working before with x64, but I guess that might have been 1.0.
The build log can be seen here: http://david.zemon.name:8111/viewType.html?buildTypeId=PropGCC5_Gcc4rpi&guest=1
BTW, I'm David, so getting Mr. Betz in here too could be quite confusing. "Altosack" is good.
Assuming you clicked a link from the "propgcc now on github" page or from PropWare's homepage or something like that (aka, anything other than directly visiting the build server), what you actually downloaded was "last successful". The words "..../lastSuccessful/..." are actually in the URL, and the TeamCity automagically finds the latest build that finished successfully. Unfortunately in the case of GCC 4 for RPi, that was back in April.
Mr. Betz, since you have access to the build server, you should be able to not only read the full build log, but also view the environment and configuration parameters for each build. Maybe you can see something there that is configured incorrectly: http://david.zemon.name:8111/viewLog.html?buildId=641&tab=buildResultsDiv&buildTypeId=PropGCC5_Gcc4rpi
There certainly is a problem with propeller-load, which doesn't recognize ttyAMA0. This console serial port is necessary to use on an embedded system, because the single USB port on the smaller boards will be used for either WiFi or for kb/mouse during development; also, any prop HAT will have it connected, anyway. I have a propeller-load that does recognize ttyAMA0; at this point, I'm not sure if I got it from Heater or a previous version of propgcc.
If no one has a ready answer, I will try the gcc5 build, and report how it goes.
You're right; it works. On the previous version I had, it would automatically find it; when that didn't work on this one, I used "-P" to find the available serial ports and it didn't find any. Curiously, I just tried it again and it did find ttyAMA0. Hmm... I suspect a permission problem that is now fixed. Sorry about that.
For info, I downloaded propgcc5-1.9.0-rpi from the link on David Zemon's page, and all of the binary files say "cannot execute binary file: exec format error" for both a Pi1 and a Pi2.
Maybe you should force a build because I believe it doesn't include, at least, the latest fixes to the assembler: I tried to compile some of my sources on the RPi and the compiler seems to not support the underscores in the number constants (like %1_0000_111).
I tried to reproduce the error on my Ubuntu Linux 64bit system which uses the latest gcc build and looks like an error when using -m32bit-doubles, without that flag the results are correct, when using the flag the results are wrong like you say (I get 278 when I should get 57.60 * 100). I tried to force casts without success, sizeof float and double seems correct, so I'm not sure what may be wrong, but since I don't use any external library, it looks like an error in the compiler itself and independent from the host system.
You can also reproduce the error without using -m32bit-doubles by using 100.0f in the code above (note the f that should force the float constant). Maybe something is not cast to the correct size internally.
It's been building every time a commit is made. They've just been failing. Something with libexpat
In any case, it works for now (and I can get back to fixing all my code bugs), because most of my speed-sensitive floating point is done by "my" (derived from Cam Thomson's, of course) routines inside of a cog, and in the future, I most likely will be bringing a lot of the higher level stuff out to the RPi, anyway.
I must say, it's very addictive to be able to ssh into my prop/pi controller from my tablet, edit the code, compile it, run it, and see the results on the tablet (yep, I replaced the "print" from SimpleText with my own already). I could even do this from town if I wanted to. Not that it makes much sense to edit code from my tablet, but I love it that I can !
A big thanks to all of you that made this possible.
Thanks for catching the error and giving such a simple reproducer!
I see the fix is for gcc5, any hint about a fix for gcc4 ?
Edit:
Nevermind, the same patch can be applied to the gcc4 tree, I was confused by the different directory layout.
Works fine with the code above, results are now correct in all cases.