GitLab

With .rodata being in FlashROM now, gap can be much smaller now. InstRAM
can be max 32K, and with segment headers, that already makes it more than
32K. Then there's some .data still, and the next Flash page boundary is
0x9000. That figure should be more or less future-proof.

TODO: Refactor makeimg to take FlashROM segment offset from file name.

Needed for frozen scripts, and for future growth of binary.

This is helpful when running on deeply embedded targets, but may be
"security risk". Caveat emptor.

Allows to re-run code if it was imported as a module (e.g., on bare-metal
ports).

Allows to re-run code if it was imported as a module (e.g., on bare-metal
ports).

And with "buffering" arg introduced, it's non possible to make it
non-kwonly.

It's ignored (unbuffered, raw I/O is used), but least makes it compatible
with CPython.

Starting with a divisor of 10, pystone_lowmem gives a score of 256.

This was originally used for non-event based REPL processing.  Then it
was unused when event-based processing was activated.  But now that event
based is disabled, and non-event based is back, there has been new ring
buffer code to process the chars.

Event-driven loop (push-style) is still supported and default (controlled
by MICROPY_REPL_EVENT_DRIVEN setting, as expected).

Dedicated loop worked even without adding ets_loop_iter(), though that
needs to be revisited later.

Before this change, if REPL blocked executing some code, it was possible
to still input new statememts and excuting them, all leading to weird,
and portentially dangerous interaction.

TODO: Current implementation may have issues processing input accumulated
while REPL was blocked.

Also, term_obj can be NULL if socket enables REPL duplication signalling
before os.dupterm is called, so it should be checked.

The idea is following: underlying interrupt-driven or push-style data source
signals that more data is available for dupterm processing via call to
mp_hal_signal_dupterm_input(). This triggers a task which pumps data between
actual dupterm object (which may perform additional processing on data from
low-level data source) and input ring buffer.

But now it's generic ring buffer implemented via ringbuf.h, and is intended
for any type of input, including dupterm's, not just UART. The general
process work like this: an interrupt-driven input source puts data into
input_buf, and then signals new data available via call to
mp_hal_signal_input().

Reference it from root pointers section.

Features inline get/put operations for the highest performance. Locking
is not part of implementation, operation should be wrapped with locking
externally as needed.

That is: aps = if0.scan()

TODO: make sure that returned list has tuple with values in "standard"
order (whatever that standard is).

Pow is already a dependency when compiling with floats, so may as well
use it here to reduce code size and speed up the conversion for most
cases.

Includes extensive test cases to catch hopefully all cases where
buffer might overflow.

When taking the logarithm of the float to determine the exponent, there
are some edge cases that finish the log loop too large.  Eg for an
input value of 1e32-epsilon, this is actually less than 1e32 from the
log-loop table and finishes as 10.0e31 when it should be 1.0e32.  It
is thus rendered as :e32 (: comes after 9 in ascii).

There was the same problem with numbers less than 1.

That's definitely helpful for debugging.

Helpful when debugging dupterm support (because otherwise all output is
spooled to dupterm too).

To use:

mp_printf(&mp_debug_print, "...");