Omnimaga
Calculator Community => Major Community Projects => The Axe Parser Project => Topic started by: Binder News on January 08, 2011, 10:14:47 pm
-
I am wondering why the maximum amount of symbols is 150. Anyone know? (Quigibo?)
-
Probably because of a buffer holding all of the symbols only allocates 150 of them.
-
Yeah, but I'm wondering HOW they are stored, and if it would be possible to compress them so as to be able to have more symbols.
-
Yeah, but I'm wondering HOW they are stored, and if it would be possible to compress them so as to be able to have more symbols.
Well, it could be possible to compress them. But it would make it harder on quigibo. I don't know the full math, but it would rely on the fact that the MSB wouldn't have to be 00h-FFh.
-
Its actually 153 now. Its because they fit conveniently onto one of the buffers since each entry is 5 bytes. 768/5 = 153. I'm already using compression so it really isn't possible to compress anymore. Of the 5 bytes, 2 are a pointer, and the last 3 hold 4 6-bit entries for the name and type of symbol.
I'm surprised you're getting this error, that's A LOT of symbols. You can reduce the count by relative referencing. Like instead of:
[1234]->Str1
[5678]->Str2
[9ABC]->Str3
Disp Str1,Str2,Str3
You can do:
[1234]->Str1
[5678]
[9ABC]
Disp Str1,Str1+2,Str1+4
Also, getting rid of Lbl's that you never actually use.
-
I'm not getting the error, but I'm making an RPG, and think I might. Why not make a pre-scan and find out how many labels are needed, then allocate that much mem in an appvar?
-
If you have 150 labels, your compiled code probably shouldn't fit in RAM anyways. :P
-
Yeah, I guess. I just have a lot of text.
-
You could put all that text in one var, and just start reading at different bytes, and that would save a lot of labels and static pointers.
-
I could, I'm just lazy and don't feel like counting all the letters.
-
The program can count it for you. If you have texts right after eachother, they are separated by zeros. So using the length command in a loop, you can create a routine to get a pointer to the Nth line of text.
-
Wait, seriously? So if I have something like this...
"Hello
"World
"A
"More text"->Str1
each line secretly has a zero tacked on to it?
-
No... but you can add the zero yourself with [00] when you aren't using the store. Also, the store should be on the first line of text, not the last one.
-
Wait, I can mix and match strings and hex?
So would this be valid?:
"Hello[20574F524C44]"->Str1
Disp Str1>Char
and would it display
HELLO WORLD
?
-
Almost:
"Hello"[20574F524C4400]->Str1
Disp Str1
-
O.O
On retrospect, that makes so much sense that I can't believe I didn't think of that.
The coolness of Axe just went up by over 9000.
-
Wait, I can mix and match strings and hex?
So would this be valid?:
"Hello[20574F524C44]"->Str1
Disp Str1>Char
and would it display
HELLO WORLD
?
Data is the same no matter what form you store it in. So
"HELLO"
is exactly the same as
Data(72,69,76,76,79)
and
[48454C4C4F]
but not
"HELLO"→Str1
since the store adds an extra [00] to the end.
-
Interesting thing about the MAX SYMBOLS error: it seems (to me) that it also has to do with how many times you call a subroutine/pointer ???
For example, today while working on Ash:Phoenix, I realized that I am multiplying by 23 quite a lot. Multiplying by 23 is very inefficient, so I decided to add a subroutine to multiply by 23. So I replaced all *23's with sub(23)'s, intending for the subroutine to be Lbl 23 : *23 : Return Since I'm lazy, I decided to compile first before adding the subroutine label so that when it gave me a missing label error, I could hit prgm to scroll to the bottom of the program and add the subroutine instead of scrolling manually.
It gave me a MAX SYMBOL error, which was strange because I had not added any new labels since the last compile It was stranger when I hit prgm to goto the error. Axe scrolled down, not to a label, but to a subroutine call (specifically, the line sub(R,0,,30,20))
Yeah...so now I'm kinda confused lol
Btw, removing all the sub(23)'s and re-replacing them with *23's led to a valid compile.
If you have 150 labels, your compiled code probably shouldn't fit in RAM anyways. :P
It did ;) (16324 bytes)
-
*23? Interesting, also if its speed you are optimizing for speed, you can do A*16+(A*7 instead of A*23, which will give you a large speed boost if you are multiplying by 23 a lot :)
-
Even better: A*12*2-A :P
And why are you multiplying by 23 so much anyways? Just wondering if it could be avoided altogether.
-
That number just happens to be how large the move database entries are :P (13 bytes for name, 1/2 for class, 1/2 for power, 6 for boosts, 1 for MP damage, 1 for HP heal, 1 for accuracy). I suppose I could add a null byte at the end of each entry which would end up costing around 100 bytes of archive space in the move appvar, but I think that *24 is probably way way better than *23 and would save a decent bit in the executable. (Or I could take class and power out of nibbles and put them into their own bytes..but man, that would screw up all the offsets...maybe it's worth it though) (It's not for speed btw)
The MAX SYMBOLS thing is weird though..does anyone know anything about that?
-
For that matter it might be better to make class and power whole bytes, as that would make each entry size 24 and probably make the retrieval of those two values a lot easier/smaller/faster.
-
I think you had 153 labels beforehand, and the edition of the Lbl R (or its call) added another, #154. Again, this is just my speculation. :P
-
No, that label (and its call) had been there for a long, long time. I compiled, it worked fine. I added nothing besides sub(23)'s, not even a Lbl 23. I gto a MAX SYMBOLS error. Removing the sub(23)'s led to an error-free compile.
-
No, that label (and its call) had been there for a long, long time. I compiled, it worked fine. I added nothing besides sub(23)'s, not even a Lbl 23. I gto a MAX SYMBOLS error. Removing the sub(23)'s led to an error-free compile.
Well, then the compiler probably saw that and said "oh, I should add a label entry for that. We'll figure out where it is in pass 2"
-
That could explain it i guess. Perhaps that particular sub(R was the first time I used it in the program...
-
If the subroutine is at the end of your code, it can't kick those calls out of the table until it finally encounters the label. Putting the subroutines at the start of the program can fix that if you use them often enough. Just make the first line of code a goto to skip over your subroutines.
Or better yet, put them in an include library so they don't crowd as much.
-
thanks