| Age | Commit message (Collapse) | Author |
|---|
|
This commit introduces the possibility of using Zcmp opcodes when
generating function prologues and epilogues, reducing the generated code
size.
With the addition of selected Zcmp opcodes, each generated function can
be up to 30 bytes shorter and having a faster prologue and epilogue. If
Zcmp opcodes can be used then register saving is a matter of a simple
CM.PUSH opcode rather than a series of C.SWSP opcodes. Conversely,
register restoring is a single CM.POPRET opcode instead of a series of
C.LWSP opcodes followed by a C.JR RA opcode. This should also lead to
faster code given that there's only one opcode doing the registers
saving rather than a series of them.
For functions that allocate less than three locals then the generated
code will allocate up to 12 bytes of unused stack space. Whilst this is
a relatively rare occurrence for generated native and viper code,
inline assembler blocks will probably incur into this penalty. Still,
considering that at the moment the only targets that support Zcmp
opcodes are relatively high-end MCUs (the RP2350 in RV32 mode and the
ESP32P4), this is probably not much of an issue.
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
|
|
This commit performs the necessary changes to handle an additional RV32
CPU extension flag, for the Zcmp extension in this case.
The changes are not limited to RV32-only code, as other parts of the
tooling need to be modified for this: the testing framework has to be
made aware that an extra bit can be set in sys.implementation._mpy and
needs to know how it is called, and "mpy-cross" must be able to actually
set that flag bit in the first place via the appropriate command line
argument.
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
|
|
This commit introduces a new generic ASM API function to clear a
register (i.e. clearing all the registers' bits).
The native emitter used to perform a XOR operation to clear a given
register, but different platform have more optimised method to achieve
the same result taking up less space - either for the generated code or
for the code generator itself.
Arm, RV32, X86, and X64 already had an already optimised generator and
generated optimised code. The code generator when build for Thumb takes
less space generating a constant immediate move rather than a XOR
operation, even though both operations would distill down to a single
narrow opcode. On Xtensa the situation is almost the same as Thumb,
with the exception that a constant immediate move would take one byte
less than a XOR operation.
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
|
|
This is unused since 007f127a61ea058ca010b85883072bdefe0234c0 "all:
Simplify mp_int_t/mp_uint_t definition".
Signed-off-by: Jeff Epler <jepler@unpythonic.net>
|
|
Signed-off-by: Damien George <damien@micropython.org>
|
|
Signed-off-by: Damien George <damien@micropython.org>
|
|
This fixes the test used by the help function to iterate over its
argument's attribute to use the proper `mp_map_slot_is_filled` function
to check if a slot in the map is filled; the previous test only checked
for `MP_OBJ_NULL` keys and would attempt to print the null value
whenever a `MP_OBJ_SENTINEL` key marking a deleted entry was present.
Fixes: #18061
Fixes: #18481
Signed-off-by: Anson Mansfield <amansfield@mantaro.com>
|
|
Prior to this change mpy-cross would fail to build under Windows with:
D:\a\micropython\micropython\py\emitinlinerv32.c(398,40): warning
C4319: '~': zero extending 'unsigned int' to 'mp_uint_t' of greater
size [D:\a\micropython\micropython\mpy-cross\mpy-cross.vcxproj]
Signed-off-by: Damien George <damien@micropython.org>
|
|
Add a cast to fix build error of mpy-cross on Windows CI.
Prior to this fix the failure was:
D:\a\micropython\micropython\py\asmbase.c(105,56): warning C4319: '~':
zero extending 'unsigned int' to 'size_t' of greater size
[D:\a\micropython\micropython\mpy-cross\mpy-cross.vcxproj]
Signed-off-by: Damien George <damien@micropython.org>
|
|
Eventually this cache flushing mechanism should be generalised to work the
same way for all architectures. But for now, this allows ESP32 RV32 SoCs
to flush the D-cache whenn needed.
Signed-off-by: Damien George <damien@micropython.org>
|
|
This commit fixes a regression introduced in
1b92bda5b8e5e2db8e57c4b7134930e52bc5207a, where a new architecture was
added to mpy-cross but it had no matching native emitter exists.
The result was that the architecture emitter entry point would be
correctly calculated according to the native architecture index, but if
the emitters entry points table was not updated to match the new number
of architectures an out of bound access may be performed.
Unfortunately adding RV64IMC shifted the debug emitter index further
down the table, and that table wasn't updated to reflect the lack of an
emitter for RV64. Adding a NULL entry there would cause a NULL pointer
access as there was no need to perform any check about the emitter entry
point function's validity until now.
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
|
|
Currently, dict views (eg `dict.keys()`, `dict.values()`) do not implement
the `bool` or `len` unary operations. That may seem like a reasonable
omission for MicroPython to keep code size down, but it actually leads to
silently incorrect bool operations, because by default things are true.
Eg we currently have:
>>> bool(dict().keys())
True
which is wrong, it should be `False` because the dict is empty.
This commit implements `bool` and `len` unary operations on dict views by
simply delegating to the existing dict unary op function.
Fixes issue #12385.
Signed-off-by: Damien George <damien@micropython.org>
|
|
The globals need to be forwarded from the caller's context.
Signed-off-by: Damien George <damien@micropython.org>
|
|
Add abort setup code `nlr_set_abort` to the standard runtime executor.
This makes the standard runtime respond to abort signal without any further
modifications.
- When aborted, the program exits with 137 exit code (configurable, same as
posix sig abort), to differentiate from a normal shutdown.
- When exited by exception/crash, the program will exit with exit code 1
(configurable).
- When exited by exception KeyboardInterrupt, the program will exit with
exit code 130 (configurable, same as posix sig int).
- When exited with a exit code (from Python environment), this code is
propagated. When a different object is passed, exit code is set to 1 and
the value printed, to be consistent with Python docs:
https://python.readthedocs.io/en/latest/library/exceptions.html#SystemExit
Signed-off-by: John Smith <jsmith@jsmith.cz>
|
|
This commit lets the native emitter generate shorter code when clearing
exception objects on RV32.
Since there are no direct generic ASM functions to set a specific
immediate to a local variable, the native emitter usually generates an
immediate assignment to a temporary register and then a store of that
register into the chosen local variable. This pattern is also followed
when clearing certain local variables related to exception handling,
using MP_OBJ_NULL as the immediate value to set.
Given that at the moment MP_OBJ_NULL is defined to be 0 (with some other
spots in the native emitter that leverage that fact when checking the
state of the variables mentioned earlier), and that the RV32 CPU has a
dedicated register that is hardwired to read 0, a new method to set
local variables to MP_OBJ_NULL is introduced.
When generating RV32 code, the new macro will skip the intermediate
register assignment and directly uses the X0/ZERO register to set the
chosen local variable to MP_OBJ_NULL. Other platforms will still
generate the same code sequence as before this change.
This is a followup to 40585eaa8f1b603f0094b73764e8ce5623812ecf.
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
|
|
This field exists to cache the lnotab field removed from v2 in #17639 by
ddf2c3afb17c0ea3dd678d02d9c2f01bed5a3020, and is now unused.
Signed-off-by: Anson Mansfield <amansfield@mantaro.com>
|
|
This commit changes the sequences generated for not-equal and
less-than-or-equal comparisons, in favour of better replacements.
The new not-equal comparison generates a sequence of equal size but
without the burden of a jump to set the output value, this also had
the effect of reducing the size of the code generator as only two
opcodes need to be generated instead of three.
The less-than-or-equal sequence, on the other hand, is actually two
bytes shorter and does not contain any jumps. If Zcb opcodes can be
used for performing the final XOR operation then two more bytes could be
saved on each comparison. The same remarks about having a shorter
generator due to two opcodes being generated instead of three still
applies here.
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
|
|
This commit shortens register-indexed load/store emitter functions, by
reusing integer-indexed equivalent operations as part of the sequence
generation process.
Before these changes, register-indexed load/store emitters would follow
two steps to generate the sequence: generate opcodes to fix up the
register offset to make it point to the exact position in memory where
the operation should take place, and then perform the load/store
operation itself using 0 as an offset from the recalculated address
register.
Since there is already a generic optimised emitter for integer-indexed
load/stores, that bit of code can be reused rather than having an ad-hoc
implementation that is tailored to operate on an offset of 0. Removing
the custom emitter code in favour of calling the general integer-indexed
emitter saves around 150 bytes without any changes in the emitter
behaviour (generating the same opcode sequence and making use of future
improvement in that emitter too).
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
|
|
This commit minimises the amount of code required to perform validation
of load/store opcodes, streamlining their validation and serialisation.
Load/store opcodes used to be handled as a special case due to how its
peculiar syntax yields parse node arguments that cannot be handled by
the regular validation and serialisation functions.
The changes in this commit attempt to reduce the amount of special code
needed for those opcodes to its bare minimum, by removing the special
opcode handling step, merging the validation and serialisation pass for
the combined offset + base register operand, and integrate said changes
in the existing argument handling structure.
That allowed to rework the special operand parsing function to make it
smaller, and remove the code that performed the special case validation
and emitted the opcode.
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
|
|
This commit simplifies the way arguments are validated when processing
RV32 inline assembler opcodes.
Opcode arguments were handled in two separate passes, one that performed
a pure validation (with an early rejection in case of errors), and
another that converted the parse node into a serialised value but
without any error checking.
Considering that the validation pass effectively performed the parse
node conversion and then discarded its result once validated, it is
preferable to hold onto the serialised result to reuse it later at
opcode generation time.
With these changes, those two passes are merged into one single
operation when applicable (basically any opcode that doesn't use an
integer offset), removing a fair amount of duplicate code. The size
savings should be around half a kilobyte, with no other changes in the
assembler's behaviour.
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
|
|
While clarifying the meaning of the arguments to `mp_quicksort`, I noticed
that by pre-adjusting the `head` argument similar to what was already done
for `tail`, code size could be saved by eliminating repeated calculation of
`h + 1`.
Signed-off-by: Jeff Epler <jepler@unpythonic.net>
|
|
This commit adds the currently supported architecture flags value as the
upper part of "sys.implementation._mpy".
This had the side effect of perturbing quite a bit of testing
infrastructure and invalidating documentation related to MPY files. To
make the test suite run successfully and keep the documentation in sync
the following changes have been made:
* The target info feature check file now isolates eventual architecture
flags and adds them as a separate field
* The test runner now picks up the new architecture flags field, reports
it to STDOUT if needed and stores it for future uses
* Relevant test files for MPY files import code had to be updated to
mask out the architecture flags bits in order to perform correctly
* MPY file format documentation was updated to show how to mask off and
properly display the architecture flags information.
This works out of the box if the flag bits can fit in a smallint value
once merged with the MPY file header value.
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
|
|
This commit introduces the MPY architecture flags checking code specific
for the RV32 target, currently checking for the only additional
extension that is supported by the runtime: Zba.
The warnings inside "mpy-cross" have also been removed since now there
is a way to reject incompatible MPY files at runtime.
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
|
|
This commit extends the MPY file format in a backwards-compatible way to
store an encoded form of architecture-specific flags that have been
specified in the "mpy-cross" command line, or that have been explicitly
set as part of a native emitter configuration.
The file format changes are as follows:
* The features byte, previously containing the target native
architecture and the minor file format version, now claims bit 6 as a
flag indicating the presence of an encoded architecture flags integer
* If architecture flags need to be stored, they are placed right after
the MPY file header.
This means that properly-written MPY parsers, if encountering a MPY file
containing encoded architecture flags, should raise an error since no
architecture identifiers have been defined that make use of bits 6 and
7 in the referenced header byte. This should give enough guarantees of
backwards compatibility when this feature is used (improper parsers were
subjected to breakage anyway).
The encoded architecture flags could have been placed at the end, but:
* Having them right after the header makes the architecture
compatibility checks occur before having read the whole file in memory
(which still happens on certain platforms as the reader may be backed
by a memory buffer), and prevents eventual memory allocations that do
not take place if the module is rejected early
* Properly-written MPY file parsers should have checked the upper two
bits of the flags byte to be actually zero according to the format
specification available right before this change, so no assumptions
should have been made on the exact order of the chunks for an
unexpected format.
The meaning of the architecture flags value is backend-specific, with
the only common characteristic of being a variable-encoded unsigned
integer for the time being.
The changes made to the file format effectively limit the number of
possible target architectures to 16, of which 13 are already claimed.
There aren't that many new architectures planned to be supported for the
lifetime of the current MPY file format, so this change still leaves
space for architecture updates if needed.
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
|
|
Assuming proper C99 language support, we can select "the int type as big as
a pointer" (most of the time) or "the 64-bit int type" (nanboxing with
REPR_D), and then define everything else automatically.
This simplifies port configuration files. And the types can still be
overridden if needed.
Signed-off-by: Jeff Epler <jepler@unpythonic.net>
|
|
Correctly format integers when there are leading zeros with a grouping
character, such as "{:04,d}".format(0x100) -> "0,256".
The new padding patterns for commas-and-zeroes and underscores-and-zeroes
are smooshed together into the existing pad_zeroes to save space.
Only the two combinations of (decimal + commas) and (other bases +
underscores) are properly supported.
Also add a test for it.
Fixes issue #18082.
Signed-off-by: Jeff Epler <jepler@unpythonic.net>
|
|
If the lookup of the module name less the leading "u" is going to succeed,
it's already a qstr (because that qstr is the key in
`mp_builtin_extensible_module_map`). So, use a function that will avoid
interning it if it's not already.
For example, if you `import unavailable` it used to intern the string
`navailable`, but now it won't.
Signed-off-by: Jeff Epler <jepler@unpythonic.net>
|
|
An empty array is a C extension supported by clang & GCC but not MSVC.
This also saves a bit of code size if there are no extensible modules.
Fixes issue #18141.
Signed-off-by: Jeff Epler <jepler@unpythonic.net>
|
|
This makes iterating on the script easier.
Signed-off-by: Jeff Epler <jepler@unpythonic.net>
|
|
This warning was enabled by default on clang 17.0.0 on macOS 26. Disable
it, because we want to make these checks at compile-time even if it
requires an extension.
Fixes issue #18116.
Signed-off-by: Jeff Epler <jepler@unpythonic.net>
|
|
Or use C++ `static_assert` when that's available.
For the same reasons that C++ has trouble with "nonconstexpr" static
assertions, `_Static_assert` rejects such expression as well. So, fall
back to the old sizeof-array based implementation in that case.
When `_Static_assert` can be used, the diagnostic quality is improved:
../py/objint.c: In function ‘mp_obj_int_make_new’:
../py/misc.h:67:32: error: static assertion failed: "37 == 42"
../py/objint.c:45:5: note: in expansion of macro ‘MP_STATIC_ASSERT’
As compared to a diagnostic about
../py/misc.h:71:50: error: size of unnamed array is negative
Testing on godbolt indicated that this actually works back to gcc 4.5, but
it's easier to use GNUC >= 5 as the test; hypothetical users of 4.5, 4.6,
or 4.7 will just get slightly worse diagnostics.
See related issue #18116.
Signed-off-by: Jeff Epler <jepler@unpythonic.net>
|
|
With the aim of getting consistency, and removing the need to learn an
additional term, replace uses of uPy/uPython with MPy/MicroPython.
Rule of thumb was to use "MPy" abbreviation where "CPy" is used nearby, but
the full word MicroPython otherwise.
This work was funded through GitHub Sponsors.
Signed-off-by: Angus Gratton <angus@redyak.com.au>
|
|
Extend mp_handle_pending to support three distinct behaviors via
mp_handle_pending_internal():
- MP_HANDLE_PENDING_CALLBACKS_ONLY: process callbacks only
- MP_HANDLE_PENDING_CALLBACKS_AND_EXCEPTIONS: callbacks + raise exceptions
- MP_HANDLE_PENDING_CALLBACKS_AND_CLEAR_EXCEPTIONS: callbacks + clear only
Original mp_handle_pending(bool) preserved as inline wrapper for
backward compatibility.
Signed-off-by: iabdalkader <i.abdalkader@gmail.com>
|
|
On LP64 and LLP64 systems, size_t is bigger than unsigned. Printing the
failed allocation using the new SIZE_FMT macro allows the correct failed
allocation size to be shown.
Example where this affects the failed allocation message (on x86_64
coverage build):
>>> "a" * (1 << 54)
Before, this would print the size as 1. Now it prints it as
18014398509481985 (2**54 + 1).
Signed-off-by: Jeff Epler <jepler@gmail.com>
|
|
Signed-off-by: Jeff Epler <jepler@unpythonic.net>
|
|
Signed-off-by: Jeff Epler <jepler@unpythonic.net>
|
|
This is needed by the zephyr port. Combining it with the existing
`MICROPY_PY_MATH_POW_FIX_NAN` option should be safe, and eliminates the
need for a separate option.
Signed-off-by: Damien George <damien@micropython.org>
|
|
Most MCUs apart from Cortex-M0 with Thumb 1 have an instruction
for computing the "high part" of a multiplication (e.g., the upper
32 bits of a 32x32 multiply).
When they do, gcc uses this to implement a small and fast
overflow check using the __builtin_mul_overflow intrinsic, which
is preferable to the guard division method previously used in smallint.c.
However, in contrast to the previous mp_small_int_mul_overflow
routine, which checks that the result fits not only within mp_int_t
but is SMALL_INT_FITS(), __builtin_mul_overflow only checks for
overflow of the C type. As a result, a slight change in the code
flow is needed for MP_BINARY_OP_MULTIPLY.
Other sites using mp_small_int_mul_overflow already had the
result value flow through to a SMALL_INT_FITS check so they didn't
need any additional changes.
Do similarly for the _ll and _ull multiply overflows checks.
Signed-off-by: Jeff Epler <jepler@gmail.com>
|
|
This change follows CPython behaviour, allowing use of:
from instance import method
to import a bound method from a class instance, eg registered via
setting `sys.modules["instance"] = instance`.
Admittedly this is probably a very rarely used pattern in Python, but it
resolves a long standing comment about whether or not this is actually
possible (it turns out it is possible!). A test is added to show how it
works.
The main reason for this change is to fix a problem with imports in the
webassembly port: prior to this fix, it was not possible to do `from
js_module import function`, where `js_module` is a JavaScript object
registered to be visible to Python through the webassembly API function
`registerJsModule(js_module)`. But now with this fix that is possible.
Signed-off-by: Damien George <damien@micropython.org>
|
|
The check for 'fits in a small int' is specific to the 31-bit int of other
object representations.
Signed-off-by: Jeff Epler <jepler@unpythonic.net>
|
|
It's frequently the case that a developer will want to compare the object
code size of various alternatives. When this can be done at the single
object code level, the turnaround is faster.
Provide a rule `$(BUILD)/%.sz` to print the size of a given object.
Because it is a normal Makefile target that depends on an object file, it
rebuilds the object file if needed.
Signed-off-by: Jeff Epler <jepler@unpythonic.net>
|
|
The magnitude of `range()` arguments is not restricted to "small" ints, but
includes "machine ints" which fit inside a register but can only be
represented as "long integer" objects in Python.
Signed-off-by: Jeff Epler <jepler@gmail.com>
|
|
This commit refactors some common code in the core stream implementation,
to reduce code size while retaining the same functionality.
With the factoring, `readinto`/`readinto1` could now support an additional
4th argument (like write) but it's best not to introduce even more CPython
incompatibility, so they are left as having a maximum of 3 args.
Signed-off-by: Damien George <damien@micropython.org>
|
|
On the zephyr port, hard IRQ handlers run with a separate stack on a
different thread, so each call to mp_irq_dispatch() and mp_irq_handler()
has to be wrapped with adjustments to the stack-limit checker.
Move these adjustments into the shared mp_irq_dispatch(), introducing
MICROPY_STACK_SIZE_HARD_IRQ which a port can define to non-zero if it
uses a separate stack for hard IRQ handlers. We only need wrap the hard
dispatch case. This should reduce binary size on zephyr without affecting
other ports.
Signed-off-by: Chris Webb <chris@arachsys.com>
|
|
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>
|
