On 2/6/2020 11:15 AM, Bill Gaylord wrote:
The real test would be to decompile an ESP32 binary and check what instruction its really using. If its using the instructions from https://0x04.net/~mwk/doc/xtensa.pdf what require the FPU option then it has to actually be using the FPU unless xtensa is not being true full of their core having an FPU.
Of course Espressif and Tensilica are telling the truth (I have a working 1200-baud TNC that wouldn't work otherwise), but knock yourself out ;-) It seems that the current level of compiler support for the Xtensa isn't very good at generating FPU code, but, I haven't invested energy into looking into it since Espressif made optimized functions available. There's also some uncertainty in my mind about the task switch behavior with respect to FPU context that may be clouding the attempts to benchmark the FPU. While I haven't looked, the lore that I recall reading is that Espressif's FreeRTOS port takes an exception the first time the FPU is used by a task, then changes behavior. One bit of lore say that FreeRTOS pins the task to that core to avoid saving FPU context, but that would mean that only two tasks (at most) could do FP, so I don't really believe it. More likely is that FreeRTOS starts going to the expense to save/restore FPU context on task switches. But, I haven't looked.
I might do some research into using Assembly to implement functions that do use the FPU instructions if it turns out the compiler if not really using them. (Which could be the case.)
So, if you need optimized DSP functions, there's this thing from Espressif called ESP-DSP that might save you the trouble of writing assembly ;-) Cheers, Dana K6JQ _______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
