issue with "compliling" code with Math expressions #1115
Replies: 10 comments
-
Posted at 2022-07-20 by @gfwilliams Hi - Thanks - I've just reproduced it here. It seems to be something to do with floating point numbers when used as function arguments. Even something like this fails:
I'll look into this now and see if it's an easy fix |
Beta Was this translation helpful? Give feedback.
-
Posted at 2022-07-20 by @gfwilliams Ok - try now! Turns out it was two issues :)
Running:
Now shows the right values for me |
Beta Was this translation helpful? Give feedback.
-
Posted at 2022-07-20 by @fanoush
the THe |
Beta Was this translation helpful? Give feedback.
-
Posted at 2022-07-20 by @fanoush Was talking about this change gfwilliams/EspruinoCompiler@d5534b6 I was thinking espruino itself is build with that convention too? Oh just checked and for nrf52 it is not while for stm32 it is! make/family/NRF52.make I'd vote for softfp calling convention as the performance difference is minimal especially when javascript uses doubles and software implementation anyway. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2022-07-21 by @gfwilliams
Ahh - yes, this makes sense - although since sending floats as function arguments isn't something that's really supported (it has to be done by a bit of a hack) it probably explains why nobody hit this before. I wasn't aware that changing from soft/hard actually changed the argument passing behaviour. nRF52 builds have been like this since at least 2017!! Changing from hard -> softfp actually seems to shave a few bytes off the firmware size, so I've committed a change - however it's a tricky one - it doesn't really help anyone on nRF52 who is using the firmware that's out there now. They'll still have the issue using any floating point numbers in code. I guess maybe I'll wait until 2v15 gets released and then switch the compiler back to using |
Beta Was this translation helpful? Give feedback.
-
Posted at 2022-07-21 by @fanoush
yes, thanks for testing, I also made a build and saw that (292300 bytes softfp vs 293468 bytes hardfp on MDBT42Q build) but did not actually test in the device. btw noticed there is also |
Beta Was this translation helpful? Give feedback.
-
Posted at 2022-07-21 by @fanoush
in inlineC it is definitely a hack as the header clearly says
so if softfp build will work fine and will stay, it might make sense to allow
to make it less hacky |
Beta Was this translation helpful? Give feedback.
-
Posted at 2022-07-21 by ioi-655321 Thank you for the quick response, I will try again and see what happens. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2022-07-21 by ioi-655321 just tested it extensivly and it works like a charm! thank you. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2022-07-22 by @gfwilliams Great! Glad it's all sorted! |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Posted at 2022-07-19 by ioi-655321
I'm using formulas to gernerate a response curve and when I use the following function it gives the wrong answer when I use the compiled keyword. It works fine without being compiled, i was wondering if there was a known issue with the Math library or if there is a simple fix
function F(x){
"compiled";
return 1/(1.13+Math.exp(-8.0*(x-0.54)))+0.14;
}
i'm running the code on the original espruino with the latest firmware.
Beta Was this translation helpful? Give feedback.
All reactions