Feature Request: Increase the Size of Propeller Tool's Symbol Table
Duane Degn
Posts: 10,588
I repeatedly run out of room in the symbol table with using the Propeller Tool.
I often get the error "Symbol table is full" after updating code in my projects. I have to go through and find variables or constants I can access without using an explicit name. I often end up typing the numeric value of a constant and leave the original named constant as a comment. Variable names are harder to eliminate.
This error wasn't as annoying with the Propeller 1 since I'd run out of RAM about the same time as running out of room in the symbol table. The Propeller 2 has so much more RAM that limited size of the symbol table is more pronounced.
I know there are other development tools which don't have this problem but my boss would like me to keep using the official Parallax IDE if possible.
Comments
I will increase the size of the various symbol tables.
symbols_limit_main = 10000h
symbols_limit_local = 1000h
symbols_limit_inline = 1000h
Any idea which ones you are running out of?
I'm pretty sure it's just the main set.
What's the current size?
I don't see how I could possibly run out when it is set to the new limit of 65,536.
Thank you very much for working on this.
Those ARE the current sizes. Do you think it's possible that you are using a whole 64KB, already?
I must be. Do long variable and constant names use up the table space faster than short names?
I assumed the 64K was the number of symbols. Since you wrote "64KB", now I'm thinking size of the names matter.
I have a tendency to use long variable and constant names. If this limit is based on the number of characters used and not the number variables/constants used, I understand why I run into this problem more than users who use short variable names.
Doubling the size of the table would be enough for my current project. Unless there are negative effects caused by greatly increasing the size, I'd think 1MB would be a good option to provide enough space to grow.
The question is: why there is a limit ? With modern computers with gigabytes of ram it doesn't seems to make any sense.
Why not use dynamic allocation with a linked list or something like that ?
OpenSpin made it so there was no limit on symbols, other than memory usage.
Chip, aren't use using a hash table for the symbols now? Should be able to just have no limit on symbols (other than memory usage).
I think the main problem is that the compiler is still written in assembler. Implementing linked lists, hash tables or variable size arrays is quite a bit of work especially debugging it. In high level languages there are standard libraries with container classes that are already well debugged.
Time to update the compiler code ?
Yes, I am using hash tables, but as someone pointed out, it's all in '386 assembly. I will boost the symbol table size to 256KB. That should solve the problem.
Yes, IF there was time to update the compiler code.
Fantastic! Thank you.
Time can be found. Need help ?
https://forums.parallax.com/discussion/173486/advanced-spin-editor-project-proposal
I'm pretty sure the size of the variable names matter.
If I abbreviate "DEFAULT" as "DFLT", my program compiles. If I use the longer name I receive the error message.
I've run into all sorts of problems when using abbreviations in variable and constant names. Abbreviations for "temperature" and "temporary" are both "temp". Integer and interval both end up as "int." I think it's much easier to make sense of older code when I use verbose variable names.
While I don't like having to shorten my variable names, this solution is still a lot easier than trying to eliminate the variable or constant entirely.
I look forward to going back to my verbose naming strategy. Thanks again Chip for working on this.
yeah Chip does not like long variable names...
That's right, msrobots. As someone said, there are two problems in computing: naming and cache invalidation. I minimize the first problem.
I just posted a new version of PNut_v35q which has 4x the symbol capacity. You can really go wild now:
https://drive.google.com/file/d/1Op4YOyFIul-7-UhRq7Cdv-OfGx5afb5M/view?usp=sharing
Lol, well, that's a challenge for you Duane!
What's needed is a facility for those wanting short variable names to be able to see a description of the variable when hovering over it in the GUI. The description could come from a comment after the original definition of the variable.
-Phil
I'm still hoping the larger symbol capacity is added to the Propeller Tool.
My boss prefers if the program will load using the Propeller Tool and I prefer the Propeller Tool myself. My brain has a hard time thinking in Spin if I don't see the all familiar colors on the screen.
I'm starting to run out of words to abbreviate in my variable names.
If the compiler benefits from short variable names, whilst humans prefer verbose, then wouldn't a precompile process solve that optimally for both parties?
Step.1. Identify all vars and constants
Step.2. Global rename to very short var names. UV1...UV34. and. UC1....UC12. for example. Optionally add the original verbose name as a comment after the code def. line, but really no one reads this intermediate code, right?
Step.3. Process usual compiler tasks and output the PASM.
This leaves the source intact and verbose, and creates the most compact PASM / symbols table possible.
Bonus.. precompile methods could deal with #ifdef type instructions too.
Are you planning on updating the Propeller Tool with larger symbol tables?
As I mentioned earlier, my brain expects the Propeller Tool colors when programming in Spin. If I need to switch to PNut, I will but I think it would be a painful transition. If there are plans to update the Propeller Tool by the end of the year, I'll stick with using the Propeller Tool.
I don't want to be a pest, but larger symbol tables in the Propeller Tool would make my life a lot easier.
You could just use PropTool for editing and do the compile/load using PNut's CLI. I do that for flexspin. Still a bit obnoxious, but at least the colors are there.
I also tried to make a VSC extension for Spin coloring once, but IIRC the highlighting is inserted such that it shows up in front of other things, kinda unworkable.
I've been doing this until today. Fortunately the latest version of the Propeller Tool includes the increased symbol table.
Thank you Chip and any others who made this work.