Replies: 6 comments
-
|
It might not work on esoteric or low quality C compilers (I'm particularly imagining that the pic16bit compiler that nobody can test with might be in that category) even though it aims to be conformant with the C/C++ standard for the preprocessor. |
Beta Was this translation helpful? Give feedback.
-
|
This was actually due to boost preprocessor having issues with commas in tuple elements. |
Beta Was this translation helpful? Give feedback.
-
|
A barrier to splitting all tables: how do you make mp_map_init_fixed_table work?
Adding a non-qstr key to a dict will do a memory allocation, when it didn't before. |
Beta Was this translation helpful? Give feedback.
-
|
Non working WIP code at https://github.com/micropython/micropython/compare/master..jepler:circuitpython:split-dict?expand=1, I'm setting this aside for now. |
Beta Was this translation helpful? Give feedback.
-
|
Interesting! What are the possible gains if applied to all the modules included in one of the standard microcontroller builds? Say for RP2040 |
Beta Was this translation helpful? Give feedback.
-
|
A quick check of RPI-pico firmware showed 6752 bytes of ROM tables (total of symbols ending _dict_table and _globals_table). This would save 1/4 of ROM table size or 1688 bytes. That's about 0.5% of the current size of the firmware. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Note: the proof of concept uses "boost preprocessor" but does not require any C++ features.
It's been noted in private communication that there is a LOT of space that could be saved in the storage of ROM tables and generally speaking all tables with strictly qstr keys. This is because (rom) qstrs are 16 bit quantities, while all table entries are pointer sized.
A different organization, in which keys are separate from values, would allow keys to be stored as 2 bytes and objects as pointer sized. It might also allow the keys of a static dictionary to be ROM while values could be RAM (i.e., the mutable entries in sys dictionary) with less support code.
For the
sysmodule of the unix standard build on a 32-bit platform this would save about 52 bytes of code space. Of course, some code space would be required for operating on tables with the new organization.A stumbling block to trying different table organization has been the textual representation of tables in source code, such as
So, let's do preprocessor crimes! The 'leading' library for this is part of Boost, and the preprocessor part can be used with pure C programs.
We just have to change the table definition like so (yes, the punctuation is a bit weird but it's what preprocessor needs):
This uses the boost preprocessor library to produce a table that's compatible with the current layout (when
ROM_TABLEisROM_TABLE_MERGED). But, you can also flip a switch and useROM_TABLE_SEPARATEwhich produces something more like.. or whatever it turns out is desirable in terms of table layout (you'd need two separate objects to enable immutable keys but mutable values, for example)
Here's how the sausage is made (early draft; see link below to current version in repo):
Beta Was this translation helpful? Give feedback.
All reactions