HP Forums
WP 34S New Build with older GCC - Printable Version

+- HP Forums (https://archived.hpcalc.org/museumforum)
+-- Forum: HP Museum Forums (https://archived.hpcalc.org/museumforum/forum-1.html)
+--- Forum: Old HP Forum Archives (https://archived.hpcalc.org/museumforum/forum-2.html)
+--- Thread: WP 34S New Build with older GCC (/thread-245432.html)



WP 34S New Build with older GCC - Marcus von Cube, Germany - 06-22-2013

I've committed a new flash build with an older GCC (4.6.0). This results in a slightly reduced user flash area. Please test if any of the strange errors reported recently persist. I'm still on the sick side of life and therefore ask you for help in this respect.


Re: WP 34S New Build with older GCC - Andrew Nikitin - 06-22-2013

Uploaded non-xtal version.

Version: 34s3.2 3418

FLASH? --> 3903 (i kind of liked previous number more)

statistics bug --> no error

fraction mode shutdown --> no shutdown


Re: WP 34S New Build with older GCC - Andrew Nikitin - 06-22-2013

LINESQ shutdown still not good. There is no shutdown, but when I performed single step it asked me "Sure?". I am pretty sure that is not what should have happened, so I pressed 8. After that calculator went into strange mode, I almost thought it is not responding to input any more. But it recovered after a few seconds.


Re: WP 34S New Build with older GCC - Andrew Nikitin - 06-22-2013

BTW, why revert to gcc 4.6.0? Just curious.


Re: WP 34S New Build with older GCC - Marcus von Cube, Germany - 06-22-2013

First of all, thanks for the tests.

To answer your question: We are using the most effective space optimization GCC offers. In an earlier phase of the project, I've had a try with the CodeSourcery GCC version that offers better optimizations. This compiler produced strange failures in parts of the code which made me revert to Yagarto GCC which proved to produce more stable code. Some GCC updates introduced by the CodeSourcery team may have been ported to the GCC main trunk (or any similar "improvements"), breaking the code generator in our special case. It's just a guess but when strange things happen in code that once used to work I think it's a good idea to check if a compiler release may have introduced the bug.

The handling of unallocated local registers in the LINEQ code may still cause strange effects due to coding errors from our side. I have to check my code. Debugging this on the hardware is almost impossible because I need to debug optimized code which is simply not designed for this.