Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.44%. Comparing base (c72a3e5) to head (17fbc5a).
Report is 8 commits behind head on master.

@@           Coverage Diff           @@
##           master   #16953   +/-   ##
=======================================
  Coverage   98.44%   98.44%           
=======================================
  Files         171      171           
  Lines       22208    22208           
=======================================
  Hits        21863    21863           
  Misses        345      345           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Code size report:

   bare-arm:    +0 +0.000% 
minimal x86:   +57 +0.030% 
   unix x64:   +32 +0.004% standard
      stm32:    -8 -0.002% PYBV10
     mimxrt:    -8 -0.002% TEENSY40
        rp2:   -16 -0.002% RPI_PICO_W
       samd:    -8 -0.003% ADAFRUIT_ITSYBITSY_M4_EXPRESS
  qemu rv32:    +8 +0.002% VIRT_RV32

The code only fails when run through mpy-cross (test option --via-mpy) The cause is the very last test, which is causing an undetected overflow:

Ah of course, thanks!

The "adding float to 64-bit long int" case I haven't dealt with here as this PR is too big already, I'll push it in a follow-up (unless you're keen to submit the fix for that, @yoctopuce?)

Thank you for asking. Feel free to do as you prefer. Let's say that if I don't see the new PR coming once this one gets integrated into the master, I will submit it :-)

bare-arm: +8 +0.014%
minimal x86: +29 +0.015%
unix x64: +0 +0.000% standard
stm32: +12 +0.003% PYBV10
mimxrt: +8 +0.002% TEENSY40
rp2: +72 +0.008% RPI_PICO_W
samd: +8 +0.003% ADAFRUIT_ITSYBITSY_M4_EXPRESS
qemu rv32: -5 -0.001% VIRT_RV32

Drat, when I tested the code size improvement from unsigned mp_parse_num() with my compiler it was a benefit on all the ports I tested. But here it's mostly neutral, and a big size hit on rp2! 😞

Drat, when I tested the code size improvement from unsigned mp_parse_num() with my compiler it was a benefit on all the ports I tested. But here it's mostly neutral, and a big size hit on rp2! 😞

The issue is because mp_small_int_mul_overflow() now takes a third argument which is the address of a local variable, and that means the variable must now be on the stack, etc.

I've pushed a commit to try and improve the situation there, by adjusting which local has it's address taken. That improves things for most ports, but others (unix, esp8266) increase a little with my change. Still, I think that's a reasonable improvement.

That change to mp_small_int_mul_overflow() to add a third arg is actually not really needed, because that function is only used in py/runtime.c in the end. So it could be reverted. I tried that but it did not decrease code size compared to my first change mentioned above.

Alright, a bit of finagling and we've got a very minor code size reduction on all the bare metal ports! 🎉

I am not sure which part is causing the minor increase in unix port sizes, but it's small enough to possibly be noise.

I've rebased and simplified the commit history (removed the parsing fixes and improvements in objint_longlong.c that were later removed entirely). Have re-run tests locally and updated the PR description with the details.

@projectgus I'm happy to squash my optimisation commit down into your commit (the one just prior to mine). I don't need the attribution for that.

@dpgeorge OK, have squashed! (And rebased agian also.)

Thanks @projectgus and @yoctopuce for your efforts here. Lots of small details have been addressed which is great!

Thanks @projectgus, you deserve all the credit. This is a really nice improvement for bare metal ports with limited ressources.