All those e0 are for nothing but inefficiently encoding initial line number of code block. As each e0 can increment line number only by 7, there is for many, many of them. Proposal: let's have initial line number encoded in a special, explicit way - for example, as VM varlen encoding, or we want more variety, as 2 bytes, but 0xffff meaning that there're another 2 bytes (recursive) to account for long source files.

This comment has been minimized.

Here is a histogram showing the frequency of having to skip n bytes and n lines. The data is collected from the CPython 3.4 stdlib, being 111,000 lines of Python code, and gives 125,000 data points (accumulated to a histogram). Note the log-log scale.

Read it as follows: more than 50% of the time, you just need to skip 1 line (the blue curve is highest at 1). The most common number of bytes to skip is 5 (the red curve is highest at 5). 0.1% of the time you need to skip more than 30 lines.

Reduces by about a factor of 10 on average the amount of RAM needed to
store the line-number to bytecode map in the bytecode prelude.
Using CPython3.4's stdlib for statistics: previously, an average of
13 bytes were used per (bytecode offset, line-number offset) pair, and
now with this improvement, that's down to 1.3 bytes on average.
Large RAM usage before was due to some very large steps in line numbers,
both from the start of the first line in a function way down in the
file, and also functions that have big comments and/or big strings in
them (both cases were significant).
Although the savings are large on average for the CPython stdlib, it
won't have such a big effect for small scripts used in embedded
programming.
Addresses issue #648.

This comment has been minimized.

Based on the above statistics (using CPython3.4 stdlib), I got it close to optimal for this suite of scripts. Original method used 13 bytes per (bytecode, line number) pair; new method uses just 1.3 on average. The method is tuned for this set of scripts, but they should be indicative of general Python scripts.

In the new method, there are 2 encoding schemes: a 1 byte one, and a 2 byte one. The 1 byte one is used for 75% of the (bytecode, line number) pairs.

Note that there are a decent amount of cases (around 10%) where large line skips occur within the function (not just the first line of the function being a large number). Thus, it's important to have the coding scheme work within functions, not just to optimise the first line being large. Also, it's simpler code not having a special case for the first function.

Also, re-enable calibration storage for CircuitPlayground Express.
Tested with a 500hz PWMOut on Metro M0 with Saleae:
* with crystal 500hz
* with usb 500hz +- 0.1hz
* without either 487hz += 0.1hz
SAMD51 is skipped due to DFLL errata and the fact it defaults to a
factory calibrated 48mhz that works fine for USB.
Fixesmicropython#648