8000 Introduce abstraction (like pointer indirection) for memory read/write? · Issue #4140 · micropython/micropython · GitHub
[go: up one dir, main page]
Skip to content

Introduce abstraction (like pointer indirection) for memory read/write? #4140

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
adritium opened this issue Sep 14, 2018 · 3 comments
Closed

Introduce abstraction (like pointer indirection) for memory read/write? #4140

adritium opened this issue Sep 14, 2018 · 3 comments

Comments

@adritium
Copy link
adritium commented Sep 14, 2018 •
edited
Loading

Memory read/write abstraction - pointer indirection - has been mentioned as a possible route #1168 to implement precise garbage collector but I think introducing such a thing has additional uses.

Remember that micropython is often run on bare-metal (cc @peterhinch ) and we're using C to implement it so we don't have the nifty tricks of operator overloading of C++ (sigh) i.e. we cannot redefine the * dereferencing operator.

Executing from flash

In #4124 I inquire of the possibility of running a .mpy from flash and @dpgeorge answers with a straightforward solution. However there is a large constraint:

The other big issue to solve would be making sure that .mpy's live in a location that is 1) memory mapped to the CPU; 2) contiguous.

If we had indirection, the code wouldn't have to be contiguous because the VM code's reading of the opcodes - switch (*ip++) - would be replaced with switch(GET(ip)) (or something).

Once you can execute from ANY flash location you can save the mp_raw_code_t to flash after you import.

RAM! (my precious)

Everyone wants to save RAM by any tricks in .py code but parsing and compilation are a huge low-ish hanging fruit. We could save the parse-tree and other artifacts in flash.
@adritium adritium changed the title Introduce abstraction (like in pointer indirection) for memory read/write? Introduce abstraction (like pointer indirection) for memory read/write? Sep 14, 2018
@dpgeorge
Copy link
Member

If we had indirection, the code wouldn't have to be contiguous because the VM code's reading of the opcodes - switch (*ip++) - would be replaced with switch(GET(ip)) (or something).

This would be a huge overhead for speed (and also code size).

There are really two discussions here: 1) general pointer indirection to help with a compacting collector; 2) supporting custom memory mapping of bytecode so it can remain in external storage.

For the latter, a more efficient and realistic approach would be to have a bytecode cache in RAM, which would hold the most recently used bytecode functions. Bytecode would be loaded on demand from storage and executed from RAM.
8000

@adritium
Copy link
Author
adritium commented Sep 20, 2018 •
edited
Loading

@dpgeorge

There are really two discussions here

You forgot save the parse-tree and other artifacts in flash

The compilation process can take way more RAM than the actual mp_raw_code_t object.
Since there's usually far more flash than RAM, it'd be nice to have the option to take longer to compile rather than fail because not enough heap.

I know I'm asking about implementing an OS-ish feature - "virtual memory lite" - but because micropython is often run on bare-metal, I think it's a valid capability to implement as part of micropython.

tannewt pushed a commit to tannewt/circuitpython that referenced this issue Feb 9, 2021
@dhalbert
Merge pull request micropython#4140 from FoamyGuy/bitmap_font_path_fix
482e583 
fix bitmap_font path in display resource gen
@dpgeorge
Copy link
Member

Closing due to inactivity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one as 3C56 signed
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@dpgeorge @adritium
0