| Age | Commit message (Collapse) | Author |
|---|
|
This commit adds support for Zba opcodes to the RV32 inline assembler.
Three new opcodes were added, SH1ADD, SH2ADD, and SH3ADD, which performs
a scaled addition (by 1, 2, or 3 bits respectively). At the moment only
qemu's VIRT_RV32 and rp2's RPI_PICO2/RPI_PICO2_W ports support these
opcodes (the latter only when using the RISCV variant).
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
|
|
This commit adds optional support for selected Zba opcodes (address
generation) to speed up Viper and native code generation on MCUs where
those opcodes are supported (namely RP2350).
Right now support for these opcodes is opt-in, as extension detection
granularity on the RISC-V platform is still a bit in flux. Relying on
the 'B' bit in the MISA register may yield both false positives and
false negatives depending on the RISC-V implementation the check runs
on.
As a side-effect of Zba support, regular non-byte load/stores have been
made shorter by two bytes. Whilst this makes code using Zba take up the
same space as non-Zba code, the former will still be faster as it will
have to process just one instruction instead of two, without stalling
registers between the shift and the addition needed to compute the final
offset.
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
|
|
This commit introduces a way for mpy-cross to pass a set of options to
the chosen emitter.
This is achieved by adding an opaque pointer to the dynamic compiler
state structure that is only accessed by emitters that have a need to
receive options from mpy-cross when generating code. That's a way to
make this feature possible without breaking any existing code or
emitter, and without re-engineering the compiler entry point function
(together with passing the options struct downstream until it's time to
emit code).
The main use case for this is letting the RV32 emitter know which
optional extensions it can generate code with, to be able to emit better
suited code for the platform in use.
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
|
|
MPY files can now hold data to be run on RV64IMC. This can be
accomplished by passing the `-march=rv64imc` flag to mpy-cross.
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
|
|
- Required for aarch64 zephyr port targets to build.
- Tested with PocketBeagle 2 [0] A53 cores.
[0]: https://docs.zephyrproject.org/latest/boards/beagle/pocketbeagle_2/doc/index.html
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
|
|
This adds comments documentign the meaning of the type flag bits
`MP_TYPE_FLAG_IS_SUBCLASSED` and `MP_TYPE_FLAG_HAS_SPECIAL_ACCESSORS`,
for consistency with the comments added later on documenting the other
flags.
These flags were were originally made part of the public API in
c3450effd4c3a402eeccf44a84a05ef4b36d69a0. This block of doc comments
was only added later on when `MP_TYPE_FLAG_EQ_NOT_REFLEXIVE`,
`MP_TYPE_FLAG_EQ_CHECKS_OTHER_TYPE`, and `MP_TYPE_FLAG_EQ_HAS_NEQ_TEST`
were added in 9ec1caf42e7733b5141b7aecf1b6e58834a94bf7.
Signed-off-by: Anson Mansfield <amansfield@mantaro.com>
|
|
Signed-off-by: Jeff Epler <jepler@unpythonic.net>
|
|
Python 2.7 has been EOL since January 2020.
Ubuntu oldoldlts (Focal Fossa, 20.04) has Python 3.8. Debian oldoldstable
(Buster, from 2019) has Python 3.7. RHEL 8 (from 2019) has Python 3.6.
It's easier than ever to install a modern Python using uv.
Given this, it seems like a fine idea to drop Python 2.7 support.
Even though the build is not tested on Python as old as 3.3, I left
comments stating that "3.3+" is the baseline Python version. However, it
might make sense to bump this to e.g., 3.10, the oldest Python 3 version
used during CI. Or, using uv or another method actually test on the oldest
Python interpreter that is desirable to support (uv goes back to Python 3.7
easily; in October 2025, the oldest supported Python interpreter version
will be 3.10)
Signed-off-by: Jeff Epler <jepler@gmail.com>
|
|
As suggested by @dpgeorge adding a `stream_write_generic()` function.
Tested the different write timeouts with a RP2 using flow control. Tested
support of the additional arguments of `uart.write()`.
Signed-off-by: robert-hh <robert@hammelrath.com>
|
|
Avoiding the double timeout when used with the UART class.
`stream.readinto1()` returns after the first timeout.
Fixes issue #17611.
Signed-off-by: robert-hh <robert@hammelrath.com>
|
|
This condition corresponds to invalid asm code like
```
@micropython.asm_rv32
def l():
a=di(a2, a2, -1)
```
and possibly other forms where nodes[0] is not a STRUCT.
Signed-off-by: Jeff Epler <jepler@gmail.com>
|
|
The calls signature for gc_malloc was changed in
5ed578e5b48730606536ded9a711223ae9a70262, without cleaning up existing
code on the rationale that the previous bool is automatically converted
to an int with the same meaning.
This commit goes back and cleans up existing invocations to make their
behavior more readable in a modern context.
Signed-off-by: Anson Mansfield <amansfield@mantaro.com>
|
|
Cleans up 24234937747e6d7fd920d21358fb26b826398e1a, and fixes builds
that include LFS but not MICROPY_ENABLE_FINALISER.
Signed-off-by: Anson Mansfield <amansfield@mantaro.com>
|
|
The Git hash is embedded in the version number. The hash is abbreviated by
Git. This commit changes the length of the Git hash abbreviation to a
fixed number, so that the length of the version string no longer varies
based on external factors (it can still vary, but will now be at least 10
characters).
This change is made because builds of the same MicroPython commit on
multiple machines were sometimes giving a version string with different
lengths, eg due to commits on other local branches having a clashing
abbreviated hash. This change may also help the code size report to be
more consistent, because it will less often be impacted by random changes
in the version string length, at the cost of always being a few bytes
longer.
Signed-off-by: Daniël van de Giessen <daniel@dvdgiessen.nl>
|
|
These files are only built on demand for developers, and it is a quick
process.
Without FORCE, a sequence like this would leave the developer with an
outdated `main.pp` to inspect:
make build-standard/main.pp
touch input.h
make build-standard/main.pp # Rebuilds now, wouldn't have before
Signed-off-by: Jeff Epler <jepler@gmail.com>
|
|
Re-organize `mp_parse_num_integer()` (for longlong) slightly so that the
most negative 64-bit integer can be parsed.
Fixes issue #17932.
Signed-off-by: Jeff Epler <jepler@gmail.com>
|
|
These functions were removed in 6c9fca2 for v1.9.3. This commit removes
their declarations as well.
See-also: 6c9fca2aa911e31f6c1b48d3b950b4dc058473d4
Signed-off-by: Anson Mansfield <amansfield@mantaro.com>
|
|
This was missed as part of the transition to make_new a mp_obj_type_t slot.
See also: 94beeabd2ee179d587942046555833e022241f24
Signed-off-by: David Schneider <schneidav81@gmail.com>
|
|
This is a pretty fundamental module, and even minimal ports like unix and
zephyr minimal have it enabled. So, enabled it by default at the lowest
feature level.
Most things in the `sys` module are configurable, and off by default, so it
shouldn't add too much to ports that don't already have it enabled (which
is just the minimal port).
Also note that `sys` is still disabled on the bare-arm port, to keep that
ultra minimal. It means we now have bare-arm without `sys` and the minimal
port with `sys`. That will allow different code size comparisons if/when
new `sys` features are added.
Signed-off-by: Damien George <damien@micropython.org>
|
|
Signed-off-by: Damien George <damien@micropython.org>
|
|
This commit unifies the configuration of MICROPY_PY_CRYPTOLIB,
MICROPY_PY_HASHLIB_MD5 and MICROPY_PY_HASHLIB_SHA1, so they are enabled by
default if MICROPY_PY_SSL is enabled. This matches the existing
configuration of most of the ports.
With this change, all ports remain the same except:
- reneses-ra now enables MICROPY_PY_CRYPTOLIB, MICROPY_PY_HASHLIB_MD5 and
MICROPY_PY_HASHLIB_SHA1.
- rp2 now enables MICROPY_PY_HASHLIB_MD5.
Signed-off-by: Damien George <damien@micropython.org>
|
|
Signed-off-by: Damien George <damien@micropython.org>
|
|
For consistency with other module-related configuration options.
Signed-off-by: Damien George <damien@micropython.org>
|
|
This is a very minor code simplification, which reduces code size by about
-8 bytes. It should have no functional change.
Signed-off-by: Damien George <damien@micropython.org>
|
|
This commit fixes the encoding of conditional branch opcodes emitted for
ARMv7-M targets, when the emitter decides to use the T3 encoding for
said operation.
Fields J1 and J2 are now present in the generated opcode word, along
with correcting some minor issues in bitmasks and shifts computation.
This fixes #17940.
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
|
|
Clang and gcc>=14 can use __has_feature() to detect if a sanitizer
is enabled, but older GCC has no mechanism - need to set a macro
explicitly for this to be recognised.
Necessary for increasing some resource limits in sanitizer builds.
Important not to use to avoid real issues!
This work was funded through GitHub Sponsors.
Signed-off-by: Angus Gratton <angus@redyak.com.au>
|
|
It's only used once, in the same file it's defined, and making it static
reduces code size.
Along with this, the associated example code comment in `ports/unix/main.c`
has been removed.
Signed-off-by: Damien George <damien@micropython.org>
|
|
They are instead checked by `binary_op_maybe()`, which catches exceptions
for invalid int/float operations.
This is a follow-up to 69ead7d98ef30df3b6bd4485633490e80fca1718
Signed-off-by: Damien George <damien@micropython.org>
|
|
CMake builds relied upon the parent Makefile removing the entire
build directory to successfully clean build artifacts.
py/mkrules.cmake: Add ADDITIONAL_CLEAN_FILES properties to ensure a
"make clean" from within the build directory removes
the genhdr and frozen_mpy directories.
Signed-off-by: Phil Howard <github@gadgetoid.com>
|
|
ringbuffer.size must be at least 2, and is a 16-bit quantity.
This fixes several cases including the one the fuzzer discovered, which
would lead to a fatal signal when accessing the object.
Fixes issue #17847.
Signed-off-by: Jeff Epler <jepler@gmail.com>
|
|
Macros in misc.h depend on values defined by including mpconfig.h.
This work was funded through GitHub Sponsors.
Signed-off-by: Angus Gratton <angus@redyak.com.au>
|
|
This adds a compile-time flag to disable some "unsafe" and non-standard
typecodes in struct, array and related modules.
This is useful to turn off when fuzzing, as improper use of these typecodes
can crash MicroPython.
Signed-off-by: Jeff Epler <jepler@gmail.com>
|
|
This commit simplifies the emitter code in charge of generating opcodes
performing less-than and less-than-or-equal comparisons.
By rewriting the SLT/SLTU opcode generator (handling less-than
comparisons) and de-inlining the less-than comparison generator call in
the less-than-or-equal generator, the output binary is ~80 bytes smaller
(measurements taken from the QEMU port).
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
|
|
Signed-off-by: Damien George <damien@micropython.org>
|
|
Signed-off-by: Damien George <damien@micropython.org>
|
|
Reproducer (needs to be run as one compilation unit):
ans = (-1) ** 2.3
aa
Fixes issue #17815.
Signed-off-by: Jeff Epler <jepler@gmail.com>
|
|
asm_thumb_store_reg_reg_offset() modifies the base register when storing
with a large offset which triggers the generic path. If a variable lives
in that register, this corrupts it. Fix this by saving the base register
on the stack before modifying it.
Signed-off-by: Chris Webb <chris@arachsys.com>
|
|
Add a new MICROPY_COMP_CONST_FLOAT feature, enabled by in mpy-cross and
when compiling with MICROPY_CONFIG_ROM_LEVEL_CORE_FEATURES. The new
feature leverages the code of MICROPY_COMP_CONST_FOLDING to support folding
of floating point constants.
If MICROPY_COMP_MODULE_CONST is defined as well, math module constants are
made available at compile time. For example:
_DEG_TO_GRADIANT = const(math.pi / 180)
_INVALID_VALUE = const(math.nan)
A few corner cases had to be handled:
- The float const folding code should not fold expressions resulting into
complex results, as the mpy parser for complex immediates has
limitations.
- The constant generation code must distinguish between -0.0 and 0.0, which
are different even if C consider them as ==.
This change removes previous limitations on the use of `const()`
expressions that would result in floating point number, so the test cases
of micropython/const_error have to be updated.
Additional test cases have been added to cover the new repr() code (from a
previous commit). A few other simple test cases have been added to handle
the use of floats in `const()` expressions, but the float folding code
itself is also tested when running general float test cases, as float
expressions often get resolved at compile-time (with this change).
Signed-off-by: Yoctopuce dev <dev@yoctopuce.com>
|
|
Following discussions in PR #16666, this commit updates the float
formatting code to improve the `repr` reversibility, i.e. the percentage of
valid floating point numbers that do parse back to the same number when
formatted by `repr` (in CPython it's 100%).
This new code offers a choice of 3 float conversion methods, depending on
the desired tradeoff between code size and conversion precision:
- BASIC method is the smallest code footprint
- APPROX method uses an iterative method to approximate the exact
representation, which is a bit slower but but does not have a big impact
on code size. It provides `repr` reversibility on >99.8% of the cases in
double precision, and on >98.5% in single precision (except with REPR_C,
where reversibility is 100% as the last two bits are not taken into
account).
- EXACT method uses higher-precision floats during conversion, which
provides perfect results but has a higher impact on code size. It is
faster than APPROX method, and faster than the CPython equivalent
implementation. It is however not available on all compilers when using
FLOAT_IMPL_DOUBLE.
Here is the table comparing the impact of the three conversion methods on
code footprint on PYBV10 (using single-precision floats) and reversibility
rate for both single-precision and double-precision floats. The table
includes current situation as a baseline for the comparison:
PYBV10 REPR_C FLOAT DOUBLE
current = 364688 12.9% 27.6% 37.9%
basic = 364812 85.6% 60.5% 85.7%
approx = 365080 100.0% 98.5% 99.8%
exact = 366408 100.0% 100.0% 100.0%
Signed-off-by: Yoctopuce dev <dev@yoctopuce.com>
|
|
This commit extracts from the current float parsing code two functions
which could be reused elsewhere in MicroPython.
The code used to multiply a float x by a power of 10 is also simplified by
applying the binary exponent separately from the power of 5. This avoids
the risk of overflow in the intermediate stage, before multiplying by x.
Signed-off-by: Yoctopuce dev <dev@yoctopuce.com>
|
|
This option is needed for ports such as webassembly where objects are
proxied and can be identical without being the same C pointer.
Signed-off-by: Damien George <damien@micropython.org>
|
|
This includes "stddef.h" for `size_t` to resolve NuttX integration build
issues.
Signed-off-by: Yanfeng Liu <yfliu2008@qq.com>
|
|
Signed-off-by: Anson Mansfield <amansfield@mantaro.com>
|
|
This commit adds support for the `__set_name__` data model method specified
by PEP487 - Simpler customisation of class creation.
This includes support for methods that mutate the owner class, and avoids
the naive modify-while-iterating hazard possible in a naive implementation
like micropython/micropython#15503.
Note that based on the benchmarks in micropython/micropython#16825, this is
also as fast or faster than the naive implementation, thanks to clever data
layout in `setname_list_t`, and the way this allows the capture step to run
during an existing loop through the class dict.
Other rejected approaches for dealing with the hazard include:
- python/cpython#72983
During the implementation of this feature for MicroPython, it was
discovered that some versions of CPython also have this naive hazard.
CPython resolved this bug in BPO-28797 and now makes a complete flat copy
of the class's dict to iterate. This design decision doesn't make much
sense for a microcontroller though, even if it's perfectly reasonable in
the desktop world where memcpy might actually be cheaper than a
hard-to-branch-predict conditional; and it's also motivated in their case
by error-tracing considerations.
- micropython/micropython#16816
This is an equivalent implementation to CPython's approach that places this
copy directly on the stack; however it is both slower and has larger code
size than the approach taken here.
- micropython/micropython#15503
The simplest implementation is to just not worry about it and let the user
face the consequences if they mutate the owner class. That's not a very
friendly behavior, though, and it's not actually much more performant than
this implementation on either time or code size.
- micropython/micropython#17693
Another alternative is to do the same as #15503 but leverage MicroPython's
existing `is_fixed` field in its dict type to convert attempted mutations
of the owner dict into `AttributeError`s. This is safer than just leaving
the open hazard, but there's still important use-cases for owner-mutating
descriptors, and the performance gain is small enough that it isn't worth
missing support for those cases.
- combined micropython/micropython#17693 with this
Another version of this feature used a new feature define,
`MICROPY_PY_METACLASSES_LITE`, to control whether this algorithm or the
naive version is used. This was rejected in favor of simplicity, based on
the very limited performance margin the naive version has (which in some
cases even goes _against_ it).
Signed-off-by: Anson Mansfield <amansfield@mantaro.com>
|
|
Current longlong implementation does not allow a float as RHS of mathematic
operators, as it lacks the delegation code present in mpz.
Signed-off-by: Yoctopuce dev <dev@yoctopuce.com>
|
|
This is to fix an outstanding TODO. The test cases is using a range as
this will exist in all builds, but `mp_obj_get_int` is used in many
different parts of code where an overflow is more likely to occur.
Signed-off-by: Yoctopuce dev <dev@yoctopuce.com>
|
|
This finding is based on fuzzing MicroPython. I manually minimized the
test case it provided.
Signed-off-by: Jeff Epler <jepler@gmail.com>
|
|
On a build like nanbox, `mp_uint_t` is wider than `u/intptr_t`. Using a
signed type for fetching pointer values resulted in erroneous results: like
`<function f at 0xfffffffff7a60bc0>` instead of
`<function f at 0xf7a60bc0>`.
Signed-off-by: Jeff Epler <jepler@gmail.com>
|
|
On the nanbox build, `o->obj` is a 64-bit type but `%p` formats a 32-bit
type, leading to undefined behavior.
Print the cell's ID as a hex integer instead.
This location was found using an experimental gcc plugin for `mp_printf`
error checking.
Signed-off-by: Jeff Epler <jepler@gmail.com>
|
|
The type of the argument must match the format string. Add casts to ensure
that they do.
It's possible that casting from `size_t` to `unsigned` loses the correct
values by masking off upper bits, but it seems likely that the quantities
involved in practice are small enough that the `%u` formatter (32 bits on
most platforms, 16 on pic16bit) will in fact hold the correct value.
The alternative, casting to a wider type, adds code size.
These locations were found using an experimental gcc plugin for `mp_printf`
error checking, cross-building for x64 windows on Linux.
In one case there was already a cast, but it was written incorrectly and
did not have the intended effect.
Signed-off-by: Jeff Epler <jepler@gmail.com>
|
