suspect-devices/circuitpython/supervisor/shared/memory.c, branch mainCircuitPython - a Python implementation for teaching coding with microcontrollershttps://git.suspectdevices.com/suspect-devices/circuitpython/atom?h=main2021-03-18T23:55:42+00:00Redo RP2040 flash settings2021-03-18T23:55:42+00:00Scott Shawcroftscott@tannewt.org2021-03-04T21:12:24+00:00urn:sha1:5d2b60cbf69c99abd6984c298d4f052514221177
This switches stage2 to C and uses Jinja to change the C code based
on flash settings from https://github.com/adafruit/nvm.toml. It
produces the fastest settings for the given set of external flashes.
Flash size is no longer hard coded so switching flashes with similar
capabilities but different sizes should *just work*.
This PR also places "ITCM" code in RAM to save the XIP cache for
code execution. Further optimization is possible. A blink code.py
still requires a number of flash fetches every blink.
Fixes #4041
run code formatting script2021-03-15T13:57:36+00:00microDev70126934+microDev1@users.noreply.github.com2021-03-15T13:57:36+00:00urn:sha1:a52eb88031620a81521b937f2a0651dbac2bb350Eliminate goto.2020-11-30T22:33:38+00:00Christian Walthercwalther@gmx.ch2020-11-30T22:33:07+00:00urn:sha1:d6f8a43f6cc755b90376a66b75818744fbe63320Optimize out allocation moving code on boards that don't need it.2020-11-29T15:27:36+00:00Christian Walthercwalther@gmx.ch2020-11-29T15:27:36+00:00urn:sha1:11ed6f86f02f61ace55951d2fff62a9d36cf3ac7
When no features are enabled that use movable allocations, supervisor_move_memory() is not needed.
Unify redundant low/high_address computation to save a bit of code size.2020-11-29T15:04:31+00:00Christian Walthercwalther@gmx.ch2020-11-29T15:04:31+00:00urn:sha1:9ecaa16eced40f3f56ba67737aed3f0950c5164fMake CIRCUITPY_SUPERVISOR_ALLOC_COUNT dependent on enabled features.2020-11-28T16:54:34+00:00Christian Walthercwalther@gmx.ch2020-10-28T20:50:28+00:00urn:sha1:993a581f5e8c039b562bbacdf17615162d8a85f6
Avoids wasted memory and makes it easier to keep track of who needs how much for future additions.
Add movable allocation system.2020-11-28T16:50:23+00:00Christian Walthercwalther@gmx.ch2020-10-11T12:59:33+00:00urn:sha1:c7404a3ff89c738c002ec63448a58d56330dfcc3
This allows calls to `allocate_memory()` while the VM is running, it will then allocate from the GC heap (unless there is a suitable hole among the supervisor allocations), and when the VM exits and the GC heap is freed, the allocation will be moved to the bottom of the former GC heap and transformed into a proper supervisor allocation. Existing movable allocations will also be moved to defragment the supervisor heap and ensure that the next VM run gets as much memory as possible for the GC heap.
By itself this breaks terminalio because it violates the assumption that supervisor_display_move_memory() still has access to an undisturbed heap to copy the tilegrid from. It will work in many cases, but if you're unlucky you will get garbled terminal contents after exiting from the vm run that created the display. This will be fixed in the following commit, which is separate to simplify review.
When there is not enough free space, but a matching hole on the other side, use it.2020-10-02T21:07:07+00:00Christian Walthercwalther@gmx.ch2020-10-02T21:07:07+00:00urn:sha1:be8092f4d32d06488df88294a9dc4bb809411c5eAllow allocate_memory() to reuse holes when matching exactly.2020-10-02T21:03:21+00:00Christian Walthercwalther@gmx.ch2020-09-29T20:21:29+00:00urn:sha1:5bdb8c45dd2700941ab75661b773680bdd46aaf1
This requires recovering the pointer of the allocation, which could be done by adding up neighbor lengths, but the simpler way is to stop NULLing it out in the first place and instead mark an allocation as freed by the client by setting the lowest bit of the length (which is always zero in a valid length).
Fix inconsistent supervisor heap.2020-10-02T21:03:21+00:00Christian Walthercwalther@gmx.ch2020-09-28T20:34:02+00:00urn:sha1:d6d02c67d2bcacaa02499930aabd76365797b108
When allocations were freed in a different order from the reverse of how they were allocated (leaving holes), the heap would get into an inconsistent state, eventually resulting in crashes.
free_memory() relies on having allocations in order, but allocate_memory() did not guarantee that: It reused the first allocation with a NULL ptr without ensuring that it was between low_address and high_address. When it belongs to a hole in the allocated memory, such an allocation is not really free for reuse, because free_memory() still needs its length.
Instead, explicitly mark allocations available for reuse with a special (invalid) value in the length field. Only allocations that lie between low_address and high_address are marked that way.