Metro M4 symbol table vs workspace allocation #define suggestion


#1

Using an Adafruit M4 Metro. Plenty of workspace; not so much symbol table.

I managed to fill my symbol table with 17K free remaining of workspace; what can I say; I’m verbose.

Searching did not find any discussion of the topic of allocating memory to workspace vs symbol table, so I read the source and experimented.

I shrunk the workspace define from WORKSPACESIZE 20480-SDSIZE to 19456-SDSIZE freeing up 1024 workspace objects.

I understand, possibly correctly, that each workspace object takes 4 bytes, so I’ve freed up 4096 bytes for use elsewhere.

I expanded the symboltable define from SYMBOLTABLESIZE 1024 to 5120 using those 4096 bytes I freed.

After a quick recompile I uploaded my gigantic lisp project and everything now fits and seems to work fine and I still have 15K or so workspace free.

I’m curious if I’m doing this correctly. Am I missing anything obvious about how arbitrary symbol names are implemented, memory allocation, unknown unknowns, etc? Obviously symbol table lookups will be slower because its larger; lack of CPU speed not really an issue on a M4.

It might be an interesting wishlist idea for larger RAM CPUs to allocate more space toward symbol tables and less toward workspace. Or if the space were allocated dynamically somehow or as a calculated ratio at compile time (rather than two sizes, spec the full size of memory and a define of my coding style uses a specified ratio of symbol table size to workspace size)

There’s a lot of abstraction in my project; a high level UI calling a graphics support library calling a tft-lcd board-level abstraction library calling a I2C expander chip-level abstraction library on the board, it rapidly fills a symbol table. Less abstract architecture style would obviously result in smaller symbol tables.

I’m having a lot of fun with uLisp and everything is going pretty well, so far.


#2

Hi Vince,

Glad you’re enjoying uLisp.

Searching did not find any discussion of the topic of allocating memory to workspace vs symbol table, so I read the source and experimented.

What you’ve done sounds correct.

Am I missing anything obvious about how arbitrary symbol names are implemented

Short symbol names, consisting of up to three characters a-z or 0-9, are effectively free, and don’t use up any space in the symbol table.

Obviously symbol table lookups will be slower because its larger

No, long symbol names are tokenised when you read in your program, so your program won’t be any slower using long names.

David