| Age | Commit message (Collapse) | Author |
|---|
|
- DTLS spec recommends HelloVerify and Anti Replay protection be enabled,
and these are enabled in the default mbedTLS config. Implement them here.
- To help compensate for the possible increase in code size, add a
MICROPY_PY_SSL_DTLS build config macro that's enabled for EXTRA and
above by default.
This allows bare metal mbedTLS ports to use DTLS with HelloVerify support.
This work was funded through GitHub Sponsors.
Signed-off-by: Angus Gratton <angus@redyak.com.au>
|
|
This is useful to distinguish between GIL and non-GIL builds.
Signed-off-by: Damien George <damien@micropython.org>
|
|
This mutes usage error for blobless update from older `git` to
reduce noise upon submodule updating.
Signed-off-by: Yanfeng Liu <yfliu2008@qq.com>
|
|
Signed-off-by: Anson Mansfield <amansfield@mantaro.com>
|
|
If big integer support is 'long long' then mp_parse_num_integer() can
parse to it directly instead of failing over from small int. This means
strtoll() is no longer pulled in, and fixes some bugs parsing long long
integers (i.e. can now parse negative values correctly, can now parse
values which aren't NULL terminated).
The (default) smallint parsing compiled code should stay the same here,
macros and a typedef are used to abstract some parts of it out.
When bigint is long long we parse to 'unsigned long long' first (to avoid
the code size hit of pulling in signed 64-bit math routines) and the
convert to signed at the end.
One tricky case this routine correctly overflows on is
int("9223372036854775808") which is one more than LLONG_MAX in decimal. No
unit test case added for this as it's too hard to detect 64-bit long
integer mode.
This work was funded through GitHub Sponsors.
Signed-off-by: Angus Gratton <angus@redyak.com.au>
|
|
Makes it compatible with the __builtin_mul_overflow() syntax, used in
follow-up commit.
Includes optimisation in runtime.c to minimise the code size impact from
additional param.
Signed-off-by: Damien George <damien@micropython.org>
Signed-off-by: Angus Gratton <angus@redyak.com.au>
|
|
Long long big integer support now raises an exception on overflow rather
than returning an undefined result.
Also adds an error when shifting by a negative value.
The new arithmetic checks are added in the misc.h header.
This work was funded through GitHub Sponsors.
Signed-off-by: Angus Gratton <angus@redyak.com.au>
|
|
This adds support for %llx (needed by XINT_FMT for printing cell objects)
and incidentally support for capitalized output of %P.
It also reduces code size due to the common handling of all integers.
Signed-off-by: Jeff Epler <jepler@gmail.com>
|
|
This commit adds a fast-path optimisation for when a BUILD_SLICE is
immediately followed by a LOAD/STORE_SUBSCR for a native type, to avoid
needing to allocate the slice on the heap.
In some cases (e.g. `a[1:3] = x`) this can result in no allocations at all.
We can't do this for instance types because the get/set/delattr
implementation may keep a reference to the slice.
Adds more tests to the basic slice tests to ensure that a stack-allocated
slice never makes it to Python, and also a heapalloc test that verifies
(when using bytecode) that assigning to a slice is no-alloc.
This work was funded through GitHub Sponsors.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
Signed-off-by: Damien George <damien@micropython.org>
|
|
This is code makes sure that time functions work properly on a
reasonable date range, on all platforms, regardless of the epoch.
The suggested minimum range is 1970 to 2099.
In order to reduce code footprint, code to support far away dates
is only enabled specified by the port.
New types are defined to identify timestamps.
The implementation with the smallest code footprint is when
support timerange is limited to 1970-2099 and Epoch is 1970.
This makes it possible to use 32 bit unsigned integers for
all timestamps.
On ARM4F, adding support for dates up to year 3000 adds
460 bytes of code. Supporting dates back to 1600 adds
another 44 bytes of code.
Signed-off-by: Yoctopuce dev <dev@yoctopuce.com>
|
|
This commit provides helpers to retrieve integer values from
mp_obj_t when the content does not fit in a 32 bits integer,
without risking an implicit wrap due to an int overflow.
Signed-off-by: Yoctopuce dev <dev@yoctopuce.com>
|
|
Signed-off-by: Anson Mansfield <amansfield@mantaro.com>
|
|
Signed-off-by: Anson Mansfield <amansfield@mantaro.com>
|
|
Signed-off-by: Anson Mansfield <amansfield@mantaro.com>
|
|
The argument corresponding to a `%q` specifier must be of type `qstr`, not
a narrower type like `int16_t`. Not ensuring this caused an assertion
error on one Windows x64 build.
The argument corresponding to a `%d` specifier must be of type `int`, not a
potentially-wider type like `mp_uint_t`. Not ensuring this prevented the
function name from being printed on the unix nanbox build.
Signed-off-by: Jeff Epler <jepler@gmail.com>
|
|
If the fields added for `MICROPY_PY_SYS_SETTRACE` are not initialized
properly, their value in a thread is indeterminate. In particular, if the
callback is not NULL, it will be invoked as a function.
Signed-off-by: Jeff Epler <jepler@gmail.com>
|
|
This commit introduces an optional feature to provide to native emitters
the fully qualified name of the entity they are compiling.
This is achieved by altering the generic ASM API to provide a third
argument to the entry function, containing the name of the entity being
compiled. Currently only the debug emitter uses this feature, as it is
not really useful for other emitters for the time being; in fact the
macros in question just strip the name away.
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
|
|
This commit cleans up the single entry point integer-indexed load/store
emitters that have been built by merging the single operand type
load/store functions in 1f5ba6998bb1895354f5afcd7bb52d83a02733be.
To follow the same convention found in RV32 and Xtensa emitters, the
function operand size is not named after the left shift amount to apply
to the initial offset to get its true byte offset, but by a generic
"operand size".
Also, those functions were updated to use the new MP_FIT_UNSIGNED macros
to perform bit width checks when figuring out which opcode encoding is
the best one to use.
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
|
|
This commit expands the implementation of Viper load/store operations
that are optimised for the x86 platform.
Like x86, x64 already implemented all necessary functions and all it
took to expose these to Viper after the infrastructure refactoring
was to add a few defines.
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
|
|
This commit expands the implementation of Viper load/store operations
that are optimised for the x86 platform.
Unlike other platforms, x86 already implemented all necessary
functions and all it took to expose these to Viper after the
infrastructure refactoring was to add a few defines.
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
|
|
This commit removes load/store opcode implementations that have been
made redundant in 1f5ba6998bb1895354f5afcd7bb52d83a02733be.
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
|
|
This commit expands the implementation of Viper load/store operations
that are optimised for the Xtensa platform.
Now both load and store emitters should generate the shortest possible
sequence in all cases. Redundant specialised operation emitters have
been aliased to the general case implementation - this was the case of
integer-indexed load/store operations with a fixed offset of zero.
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
|
|
This commit expands the implementation of Viper load/store operations
that are optimised for the Arm platform.
Now both load and store emitters should generate the shortest possible
sequence in all cases. Redundant specialised operation emitters have
been folded into the general case implementation - this was the case of
integer-indexed load/store operations with a fixed offset of zero.
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
|
|
This commit expands the implementation of Viper load/store operations
that are optimised for the RV32 platform.
Given the way opcodes are encoded, all value sizes are implemented with
only two functions - one for loads and one for stores. This should
reduce duplication with existing operations and should, in theory, save
space as some code is removed. Both load and store emitters will
generate the shortest possible sequence (as long as the stack pointer is
not involved), using compressed opcodes when possible.
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
|
|
This commit adds two macros that lets check whether a given value can
fit an arbitrary number of bits, either as a signed or as an unsigned
number.
The native emitter code backends perform a lot of bit size checks to see
if a particular code sequence can be emitted instead of a generic one,
and each platform backend has its own ad-hoc macros (usually one per bit
count and signedness).
With these macros there's a single way to perform those checks, plus
there's no more chance for off-by-one mask length errors when dealing
with signed numbers.
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
|
|
Tested using gcc 7.3.1 which does not have the popcount built-in and uses
this fallback version. Without the fix, mpy-cross produces mpy files with
corrupt RISC-V machine code. With the fix, mpy-cross output is correct.
Signed-off-by: Damien George <damien@micropython.org>
|
|
CPython math.nan is positive with regards to copysign. The signaling bit
(aka sign flag) was incorrectly set.
In addition, REPR_C and REPR_D should only use the _true_ nan to prevent
system crash in case of hand-crafted floats. For instance, with REPR_C,
any nan-like float following the pattern
`01111111 1xxxxxxx xxxxxxxx xxxxx1xx` would be switched to an immediate
object or a qstr string. When the qstr index is too large, this would
cause a crash.
This commit fixes the issue, and adds the relevant test cases.
Signed-off-by: Yoctopuce dev <dev@yoctopuce.com>
|
|
When the symbol `__all__` is defined in a module, `mp_import_all()` should
import all listed symbols into the global environment, rather than relying
on the underscore-is-private default. This is the standard in CPython.
Each item is loaded in the same way as if it would be an explicit import
statement, and will invoke the module's `__getattr__` function if needed.
This provides a straightforward solution for fixing star import of modules
using a dynamic loader, such as `extmod/asyncio` (see issue #7266).
This improvement has been enabled at BASIC_FEATURES level, to avoid
impacting devices with limited ressources, for which star import is of
little use anyway.
Additionally, detailled reporting of errors during `__all__` import has
been implemented to match CPython, but this is only enabled when
ERROR_REPORTING is set to MICROPY_ERROR_REPORTING_DETAILED.
Signed-off-by: Yoctopuce dev <dev@yoctopuce.com>
|
|
Any '_' variables/functions in frozen modules are currently printed, when
they shouldn't be. That's due to underscore names possibly existing
between the start and end qstrs which are used to print the auto-complete
matches. The underscore names should be skipped when iterating between the
two boundary qstrs.
The underscore attributes are removed from the extra coverage exp file
because tab completing "import <tab>" no longer lists modules beginning
with an underscore.
Signed-off-by: Andrew Leech <andrew.leech@planetinnovation.com.au>
|
|
Previously, there was no test coverage of the "write failed" path. In
fact, the assertion would fire instead of gracefully raising a Python
exception.
Slightly re-organize the code to place the assertion later. Add a test
case which exercises all paths, and update the expected output.
Signed-off-by: Jeff Epler <jepler@gmail.com>
|
|
By ensuring the value to be shifted is an unsigned of the appropriate type.
This fixes several runtime diagnostics such as:
../../py/binary.c:199:28: runtime error:
left shift of 32768 by 16 places
cannot be represented in type 'int'
Signed-off-by: Jeff Epler <jepler@gmail.com>
|
|
In the case of viper code it's possible to reach MP_ASM_PASS_EMIT with a
code size of 0 bytes. Update the assertion accordingly.
After this change, `mpy-cross -march=debug' on viper tests no longer
crashes.
Fixes issue #17467.
Signed-off-by: Jeff Epler <jepler@gmail.com>
|
|
Looking at the git history, there's no indication that the
`PF_FLAG_NO_TRAILZ` flag was ever implemented or that "%!" was used as an
`mp_printf` format string in practice.
So remove the flag and re-number the other flags.
Leave `PF_FLAG_SEP_POS` at 9 (the highest position that probably works with
16-bit integers like the pic16bit port).
Signed-off-by: Jeff Epler <jepler@gmail.com>
|
|
By refactoring the code to separate out the slicing operation from the
regular indexing operation, code can be shared between the various types of
slice operations (read/assign/delete).
Signed-off-by: Jeff Epler <jepler@gmail.com>
|
|
In the case where an mpz number is zero, its `len` is 0 and its `dig` is
NULL. In that case, decrementing NULL via `d--` is undefined behavior
according to the C specification.
Restructuring the loops in this way avoids undefined behavior.
Also, ensure that these cases are tested in the coverage test. This
doesn't make much difference now, but would otherwise cause errors later
when the undefined behavior sanitizer is employed in CI.
Signed-off-by: Jeff Epler <jepler@gmail.com>
|
|
It's actually a bug in the Windows SDK, not MSVC, as per
https://stackoverflow.com/questions/79195142/recent-msvc-versions-dont-treat-nan-as-constant-workaround/79324199#79324199
Thanks to @stinos.
Signed-off-by: Damien George <damien@micropython.org>
|
|
If a complex literal had a negative real part and a positive imaginary
part, it was not parsed properly because the imaginary part also came out
negative.
Includes a test of complex parsing, which fails without this fix.
Co-authored-by: ComplexSymbol <141301057+ComplexSymbol@users.noreply.github.com>
Signed-off-by: Jeff Epler <jepler@gmail.com>
|
|
As suggested by @dpgeorge, factor out part of array_construct to allow it
to be used for construction & extension.
Note that extending with a known-length list (or tuple) goes through the
slow path of calling array_extend once per element.
Fixes issue #7408.
Signed-off-by: Jeff Epler <jepler@gmail.com>
|
|
A few more bytes can be saved by not using nested `if`s (4 bytes for
`build-MICROBIT/py/parsenum.o`, 8 bytes for RPI_PICO firmware).
This commit is better viewed with whitespace changes hidden, because
two blocks were reindented (e.g., `git show -b`).
Signed-off-by: Jeff Epler <jepler@gmail.com>
|
|
By avoiding two different checks of the string length, code size is reduced
without changing behavior: Some invalid float/complex strings like "ix"
will get handled just like "xx" in the main number literal parsing code
instead.
The optimizer alone couldn't remove the reundant comparisons because it
couldn't make a transformation that let an invalid string like "ix" pass
into the generic number parsing code.
Signed-off-by: Jeff Epler <jepler@gmail.com>
|
|
Soft float now works on these ARM targets thanks to the parent commit.
Signed-off-by: Damien George <damien@micropython.org>
|
|
With this change, all tests (except thread tests) now pass on RPI_PICO when
using the native emitter:
(plug in RPI_PICO)
$ cd tests
$ ./run-tests.py -t a0 --via-mpy --emit native
Signed-off-by: Damien George <damien@micropython.org>
|
|
This commit lets the native emitter backend extends the range of the
BCC family of opcodes (BALL, BANY, BBC, BBS, BEQ, BGE, BGEU, BLT,
BLTU, BNALL, BNE, BNONE) from 8 bits to 18 bits.
The test suite contains some test files that, when compiled into native
code, would require BCC jumps outside the (signed) 8 bits range. In
this case either the MicroPython interpreter or mpy-cross would raise an
exception, not running the test when using the "--via-mpy --emit native"
command line options with the test runner.
This comes with a 3 bytes penalty on each forward jump, bringing the
footprint of those jumps to 6 bytes each, as a longer opcode sequence
has to be emitted to let jumps access a larger range. However, this is
slightly offset by the fact that backward jumps can be emitted with a
single opcode if the range is small enough (8-bits offset).
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
|
|
This commit lets the native emitter backend extends the range of the
BCCZ family of opcodes (BEQZ, BNEZ, BLTZ, BGEZ) from 12 bits to 18
bits.
The test suite contains some test files that, when compiled into native
code, would require BCCZ jumps outside the (signed) 12 bits range. In
this case either the MicroPython interpreter or mpy-cross would raise an
exception, not running the test when using the "--via-mpy --emit native"
command line options with the test runner.
This comes with a 3 bytes penalty on each forward jump, bringing the
footprint of those jumps to 6 bytes each, as a longer opcode sequence
has to be emitted to let jumps access a larger range. However, this is
slightly offset by the fact that backward jumps can be emitted with a
single opcode if the range is small enough (3 bytes for a 12-bits
offset).
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
|
|
This commit performs a small refactoring on the Arm native emitter, by
renaming all but one instance of ASM_ARM_REG_R8 into REG_TEMP.
ASM_ARM_REG_R8 is the temporary register used by the emitter when
operations cannot overwrite the value of a particular register and some
extra storage is needed.
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
|
|
This commit extends the range for int-indexed load/store opcode
generators, making them emit correct code sequences for offsets that
span more than 12 bits.
This is necessary due to those generator bits being also used in the
Viper emitter, where it's more probable to reference offsets that can
not be embedded in the LDR/STR opcodes.
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
|
|
This commit removes redundant RV32 implementations of certain
int-indexed code generation operations (32-bit load/store and 16-bit
load).
Those operations were already available as part of the native emitter
API but were not exposed to the Viper code generator. As part of the
introduction of more specialised load and store API calls to
int-indexed Viper load/store generator bits, the existing native emitter
implementations are reused, thus making the Viper implementations
redundant.
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
|
|
This commit updates the existing specialised implementations for
int-indexed 32-bit load and store operations, and adds a specialised
implementation for int-indexed 16-bit load.
The 32-bit operations relied on the fact that their applicability was
limited to a specific range, falling back on a generic implementation
otherwise. Introducing a single entry point for each int-indexed
load/store operation size would break that assumption. Now those two
operations contain fallback code to generate working code by themselves
instead of raising an exception.
The 16-bit operation instead simply did not have any range check, but it
was not exposed directly to the Viper emitter. When a 16-bit
int-indexed load entry point was introduced, the existing implementation
would fail when accessing memory outside its 0..255 halfwords range. A
specialised implementation is now present, performing fewer operations
than the existing Viper emitter equivalent.
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
|
|
This commit lets the Thumb native code generator backend emit ARMv7-M
specific opcodes for indexed load/store operations if possible.
Now T3 opcode encodings are used if the generator backend is configured
to allow emitting ARMv7-M opcodes and if the (unsigned) scaled index
fits in 12 bits. Or, in other words, LDR{B,H}.W and STR{B,H}.W opcodes
are now emitted if possible.
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
|
|
This commit extends the generic ASM API by adding the rest of the
ASM_{LOAD,STORE}[size]_REG_REG_OFFSET macros whenever applicable.
The Viper int-indexed load/store code generator was changed to use those
API functions if they are available, falling back to backend-specific
implementations if possible and ultimately to a generic implementation.
Right now all backends except for x64 implement load16, load32, and
store32 operations (x64 only implements load16).
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
|
