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
• ev3-firmware-build-4298-git6398e3db.zip
• movehub-firmware-build-4298-git6398e3db.zip
• cityhub-firmware-build-4298-git6398e3db.zip
• primehub-firmware-build-4298-git6398e3db.zip
• technichub-firmware-build-4298-git6398e3db.zip
• essentialhub-firmware-build-4298-git6398e3db.zip
• nxt-firmware-build-4298-git6398e3db.zip

[coveralls]

coverage: 59.78%. remained the same
when pulling ab6e86e on CSUPEROPT
into 2488153 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 😄