bricks/_common/Makefile: Enable CSUPEROPT for smaller binaries.

[laurensvalk]

Looks like we were missing considerable savings with this build option.

Reduces build size:

• Move Hub: -2400
• Technic Hub: -2332

Looks like MicroPython enables this for:

ifeq ($(MCU_SERIES),$(filter $(MCU_SERIES),f0 g0 l0))
CSUPEROPT = -Os # save some code space

For everything else:

# some code is performance bottleneck and compiled with other optimization options
CSUPEROPT = -O3

Which is probably to optimize for speed. We also find in the MicroPython source:

# Force nlr code to always be compiled with space-saving optimisation so
# that the function preludes are of a minimal and predictable form.
$(PY_BUILD)/nlr%.o: CFLAGS += -Os

# optimising gc for speed; 5ms down to 4ms on pybv2
$(PY_BUILD)/gc.o: CFLAGS += $(CSUPEROPT)

# optimising vm for speed, adds only a small amount to code size but makes a huge difference to speed (20% faster)
$(PY_BUILD)/vm.o: CFLAGS += $(CSUPEROPT)
# Optimizing vm.o for modern deeply pipelined CPUs with branch predictors
# may require disabling tail jump optimization. This will make sure that
# each opcode has its own dispatching jump which will improve branch
# branch predictor efficiency.
# https://marc.info/?l=lua-l&m=129778596120851
# http://hg.python.org/cpython/file/b127046831e2/Python/ceval.c#l828
# http://www.emulators.com/docs/nx25_nostradamus.htm
#-fno-crossjumping

[laurensvalk]

So maybe we should follow and only apply it to F0 (City Hub and Move Hub)? Although Technic Hub is closer to the space limit than City Hub, so could be worth doing that if we don't mind the speed penalty. I.e. perhaps do it on Move Hub only.

[github-actions]

Download the artifacts for this pull request:

• pr_number.zip
• mpy-cross.zip
• movehub-firmware-build-4360-git3588ad1b.zip
• nxt-firmware-build-4360-git3588ad1b.zip
• technichub-firmware-build-4360-git3588ad1b.zip
• primehub-firmware-build-4360-git3588ad1b.zip
• ev3-firmware-build-4360-git3588ad1b.zip
• cityhub-firmware-build-4360-git3588ad1b.zip
• essentialhub-firmware-build-4360-git3588ad1b.zip

[coveralls]

coverage: 57.143%. remained the same
when pulling 0b854ba on CSUPEROPT
into 3fe9ffc on master.

[dlech]

Apparently that comment has a different idea about what small code size is. 😮

Sounds reasonable to use -Os for this on hubs that are getting close to full.

[laurensvalk]

Apparently that comment has a different idea about what small code size is. 😮

20% speed increase for 0.5% build size (2K on 400K builds) is probably worth it for most boards where space is not an issue. We can make the trade-off the other way.

Sounds reasonable to use -Os for this on hubs that are getting close to full.

👍

I came across this option as I was working on a new embedded simulation build (which had it enabled by default), so even if this is all to come out of that, it was worth it 😄

[laurensvalk]

On Technic Hub, the savings are 2400 bytes at a reduction of only 635 to 611 pystones/sec, so -4%, which is certainly worth it.

[laurensvalk]

The savings are even larger, but we are also seeing that there was a big initial bump in size on going to MicroPython 1.26.

For Move Hub, there wasn't a jump when going to 1.26:

So it might have been a specific feature rather than the base becoming much larger. And maybe this feature isn't needed on Technic Hub either. Part of this is floating point support, but this covers only a portion of the increase (about 350 bytes).