Parallella Community

notzed,

Thanks for bringing this up!

The different modes can be seen here an
http://gcc.gnu.org/onlinedocs/gcc-4.8.1 ... ny-Options

Here are some thoughts/history on the subject for everyone:
-We don't have a native integer multiply instruction in the integer ALU and instead reuse the FPU datapath
-The integer arithmetic mode in the CONFIG converts the FPU to a secondary integer unit capable of IMUL, IMADD, etc

To get more efficient code, you can use the -mfp-mode. The default is the more robust "caller" mode.
-mfp-mode=int
-mfp-mode=round-nearest

If this is still not good enough let us know...I am sure there is a way to fix it.

What's the thing with r16 in that code, is that just a bug or am I missing something? That's the full int routine so it's value isn't known when it is used?

Is the reason for that strange restore routine something to do with preserving the other bits of the config register that might have changed by higher-priority code? If the fpu mode was in/shadowed in a separate register that could simply be a movts (something to think about for a silicon revision, if an imul isn't a possibility).

That's strange indeed. Did you try linking this with a meaningful program and see if the compiler assumed something about a global use of R16 (I could not find any in CRT0, though)?

What compiler options did you use?

Is it possible that it is (erroneously) the "-1" constant register (set by option -m1reg-reg, see the options in the link Andreas provided above).

An analysis and patch for this bug are at:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60651