pico: revert using nano.specs

[Daft-Freak]

I added this to avoid bloat from exception related stuff in libstdc++, but there's a problem.

• newlib-nano is usually built with -Os, this results in disabling the optimised memcpy/memset/... implementations.
• The fallback implementation just copy/fill bytes. Very small, but not fast.
• RP2040 has an optimised memcpy/memset in the bootrom so these aren't used in the end. RP2350 does not... so they do.
• GCC tries to be smart and optimises anything that looks like a memcpy to a memcpy (similar for memset), but if you were copying words it makes it 4x slower.

So, this goes back to the default but tries to keep most of the space savings by avoiding the default terminate handler.

For a somewhat extreme performance comparison, this is 15 -> 10ms on my 3d engine (rasterise time).

Size comparison:

logo before (with nano.specs)

  text    data     bss     dec     hex filename
282432       0  319696  602128   93010 examples/logo/logo.elf

logo without nano.specs

  text    data     bss     dec     hex filename
313484       0  320524  634008   9ac98 examples/logo/logo.elf

(ouch, +31k)

logo after (without nano.specs, overridden terminate handler)

  text    data     bss     dec     hex filename
288736       0  320516  609252   94be4 examples/logo/logo.elf

(just +6.3k)

(32blit-stm32 has a similar problem, which we can fix there by rebuilding our custom newlib with -O2 (+3k on logo, +2.4k on firmware))

[Gadgetoid]

I am reminded of this video which I need to watch again - https://www.youtube.com/watch?v=bY2FlayomlE

Judging by your findings here, I should probably not be using https://github.com/pimoroni/pimoroni-pico/blob/main/micropython/modules/micropython-disable-exceptions.cmake in MicroPython builds 😬

[Daft-Freak]

It does seem to depend on the toolchain (I got the fast memcpy when I tried the default ubuntu toolchain, but not with the default arch one), but yeah...

The only way to be sure is digging in the disassembly:

I need to see if there's any huge wins on stm32 stuff as we've been using the slow copies since adding the PIC stdlibs, maybe even before that 🤔