Omnimaga
Calculator Community => Major Community Projects => The Axe Parser Project => Topic started by: Quigibo on February 12, 2010, 06:49:39 pm
-
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:
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:
AND 150:
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.
-
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! :)
-
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! :)
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.
-
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
-
I can't wait!
Hopefully I can get this on my school calc soon.
-
Nice, I don't mind slower compiling speed. Compiling a big ASM prog on a 350 GHz comp with TASM alerady took long enough anyway :P
-
I don't mind slower compiling at all, if it means more variables ( although 150 is a lot to a basic programmer :P) just make sure to add a loading bar ;)
-
The new method seems the best. Having to wait a bit longer for it to compile doesn't seem like that big of a deal to me either.
-
yeah, actually this new method is a bit like assemblers :P
also, I finally was able to sneak it on my school calc, so I can play around with it. can't wait for the updated one though.
-
Good news! After a very gruesome debugging session (but not as brutal as I've had before), I've finally finished rewriting the entire symbol table handling. I think it works now, at least, it hasn't failed me yet and it runs past example programs fine. Definitely expect the next release on time, but I've got far too much to do before I can start adding sprite support, that will have to wait just a bit longer.
-
That's good! I can't wait!
-
Awesome! I think I'll put 0.0.4 on my calc. ;D
-
Glad to hear :)
Can't wait to see new version :)
(as for debugging sessions, they can be quite frustrating. Sometimes you are tempted to use an hammer)
-
...(as for debugging sessions, they can be quite frustrating. Sometimes you are tempted to use an hammer)
Epic statement. When I get up to debugging in my TI Basic game design tutorial, that is definately being cited.
-
Lol
Poor calc, though :(
-
Lol. Visual of statement:
*DJ begins the debugging proccess*
*Calc outputs Err: Dim Mismatch*
<DJ> (angry): I'll show you a dimension mismatch. *Bashes with Hammer*
*A few minutes pass. Calc outputs Err: Memory*
<DJ> (enraged): Maybe I'll knock some memory into you. *smashes some more*
-
lol, usually the hammer comes into action only after several attempts, though :P
-
Lol. I'm just trying to make the "Funny Quotes" thread. lol. jk. not really. but, yeah. I sometimes get so angry during the debugging process. But, the worst is when I spend like three days not being able to find the error, and ready to get the hammer, then on the fourth day, realize that that is something so stupid like an extra comma or something, then I want to whack myself with the hammer. (well, not really, but u get the point).
-
Yeah like Quigibo recent bugs x.x