Calculator Community > The Axe Parser Project

Rewriting The Core

(1/4) > >>

Quigibo:
Unfortunately, do to the limitation of the calculator's available RAM, I am pretty much going to have to re-write the entire core of the program.  No one has notice the problem yet because all the example programs are small and don't require a lot of user specified data.  Once you start getting into medium and large sized programs, it will become a very big issue.

I will share the method I am using, the method I am planning on using, and other methods I've thought of to to see if maybe someone has a better idea before I start rewriting it.

THE OLD METHOD
The old method was to do a single pass.  Every time a label or name is encountered, it is added to the symbol table so that at the end of the programs, all the symbols are replaced.  All declared data like strings, pictures, sprites, and lists are added to the end of the program as it is being written and also to the symbol table.  The symbol table can only hold 150 entries and it really can't be expanded beyond that by much so that means you can only have 150 combined:


* Labels
* Name declarations
* Name references
ALTERNATIVE METHOD #1
Store all the data at the beginning of the program, that way once a variable is defined, you know exactly where the data is (since the expansion of the program doesn't push the data down further) so that way you don't need to add name references to the symbol table.  The down side is that now the labels are going to be pushed down as data is added to the top so I need to add all the label references  as well.  Also, a 3 byte increase in program size.  So 150 combined:


* Labels
* Gotos
* Name declarations
ALTERNATIVE METHOD #2
Same as alternative #1 except that the programmer is forced to define all variables at the beginning of the program instead of allowing variables to be defined within the program.  That way, the labels don't get pushed down as the program is being created.  Its kind of a slight inconvenience to the programmer though, and you would almost surely want to define the variables in a separate subprogram so that you don't have to keep scrolling all the way down to edit your code.  150 of:


* Labels
* Name declarations
THE NEW METHOD
2 passes are made.  In the first pass, all name declarations are skipped and name references are left blank so that no data is being added to the end of the program.  That way, only labels are kept track of the first pass.  Then on the second pass, the opposite happens.  All regular code is skipped, since it already was written in the first pass,
but all data is written to the end where it won't ever be pushed further down, so I don't need to keep track of references.  Disadvantage is that compiling will take about 1.5x longer and also I have to rewrite most of the core, but I think these leave a far more reasonable amount of variables:

150:

* Labels
AND 150:

* Name declarations
Don't forget, arrays of sprites count as 1 variable.  So if you have 20 8x8 sprites each representing a number on a grid, you can just store all of them consecutively to Pic1 and then reference them as Pic1, Pic1+8, Pic1+16, etc. or even Pic1+A.  Theoretically you can do this with strings too, but its a little harder since each string is probably a different size and you also have to take the terminating character into account.

ztrumpet:
Awesome!  This is fascinating.  I like the new method, and I don't mind the speed decrease.  It sounds really cool.  Does DelVar-ing a variable mean that there can be more than the 150, or not?  This is cool! :)

Quigibo:

--- Quote from: ztrumpet on February 12, 2010, 09:12:08 pm ---Awesome!  This is fascinating.  I like the new method, and I don't mind the speed decrease.  It sounds really cool.  Does DelVar-ing a variable mean that there can be more than the 150, or not?  This is cool! :)

--- End quote ---
Yes, if you delete a label, it is deleted from the symbol table and you can add more labels, including one with the same name as the one you deleted.  You will probably be able to do the same thing with sprites in the future.

So once you use the sprite/label and you don't need to reference it again, deleting it (you're really just deleting the name not the actual data) will allow you to free up more room for more sprites/labels.

ztrumpet:
Yay!  That's great!  I can't wait untill I try to make games with this.  I havn't tried yet, but I really, really should.  ;D

Eeems:
I can't wait!
Hopefully I can get this on my school calc soon.

Navigation

[0] Message Index

[#] Next page