Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: Deep Toaster on October 13, 2010, 11:52:51 am
-
I know that programs can't be more than 8811 bytes, or else they could crash when the TI-OS gets near the end, but that data can be stored there. But I heard that in Axe, data and subroutines are mixed, so does that mean that I shouldn't make programs more than 8811 bytes, even if they have a lot of data at the end?
-
In Axe it only counts executable code. You can still have as much data as the rest of the RAM can hold (well, almost, so you can run the game lol)
-
I think Quigibo mentioned somewhere that the subroutines used by commands could be mixed in with the data, though, so I'm not sure if it could work...
-
Oh right I remember that. I think that won't make much difference in the end, though, when it comes to executable code size. However, maybe he could confirm in case...
-
Hmm, I guess people could use Calcsys to check if there's code near the end...
-
Data is always at the end of the program, what he means by mixing code and data is that in your source, you can reference data inside your code, instead of declaring it somewhere else
-
I could have sworn that at some point Quigibo said he was mixing subroutines (for built-in commands and Axioms) with data...
This would mean that code and data are mixed and code will probably appear at the end of the program.
Quigibo will have to confirm this, of course.
-
Yeah, the code is compiled like this:
[ Header ]
[ Compiled Code ]
[ Data and AxCalls ]
The data is mixed with the Axe subroutines (which I am calling AxCalls now so you don't confuse them with user defined subroutines). So these are not the subroutines that you call with sub() they are the routines used by Axe itself such as DispGraph, multiplication, static data, and interrupts for example. They are in the order that you define them in the code so generally, when you define your data in the beginning of the code, the data is defined before your first call to the AxCalls. So usually it looks like this:
[ Header ]
[ Compiled Code ]
[ Data ]
[ AxCalls ]
It is possible to have a 3rd pass to determine all the AxCalls you use in the program and add those first before adding the data but I'm really trying to avoid that becasue it would require a lot of code rewriting and would take 50% longer to compile.
-
Ah, so if I put my data after my subroutines (after all the actual code), it should be safe?
-
Does Axe support forward references yet? If so, yes.
-
Nope :(
-
Does Axe support forward references yet? If so, yes.
What are forward references? Are they references to data further down in the program?
-
Yeah, the code is compiled like this:
[ Header ]
[ Compiled Code ]
[ Data and AxCalls ]
The data is mixed with the Axe subroutines (which I am calling AxCalls now so you don't confuse them with user defined subroutines). So these are not the subroutines that you call with sub() they are the routines used by Axe itself such as DispGraph, multiplication, static data, and interrupts for example. They are in the order that you define them in the code so generally, when you define your data in the beginning of the code, the data is defined before your first call to the AxCalls. So usually it looks like this:
[ Header ]
[ Compiled Code ]
[ Data ]
[ AxCalls ]
It is possible to have a 3rd pass to determine all the AxCalls you use in the program and add those first before adding the data but I'm really trying to avoid that becasue it would require a lot of code rewriting and would take 50% longer to compile.
What are AxCalls? Axioms?
-
They're the subroutines used in ASM. For example, multiplication by some arbitrary number takes a lot more than a couple simple commands, so to save space, a subroutine to multiply two numbers is added at the end, and whenever the program multiplies numbers, it calls the subroutine. Apparently, it's these subs that can be mixed with data, so that's a problem x.x
-
You mean stuff ran with Asm()?
-
He means like DispGraph. The code for dispgraph is say 100 bytes, so to save space Axe puts it at the bottom of your program, and whenever you use DispGraph in your program, it calls it (kinda like sub()) from the bottom to save space
-
Oh ok, ty for the info.
-
For a more technical reason why the parser works this way, I'll explain how each pass in the parser works:
First, the entire program is parsed EXCEPT for data and AxCalls. Whenever it encounters an AxCall, it writes a "call XXXX" to the executable and moves on because the actual location of the routine can't be determined until the size of the executable is known. Same with data. If you used Str1 somewhere in your code it will replace the value of that pointer with XXXX as well and just continue as if nothing was wrong. By the end of the first pass, the program is completely parsed but with a bunch of holes that need filling.
Then, the second pass happens. The compiler does exactly the same thing, but in exactly the opposite way. It scans through the program and anything that is not an AxCall or data is ignored (since it was already written in the first pass) but when it encounters one of these holes, it can now add that data/routine to the end of the program since we know where that is now. It then takes the address of that location it just added and uses that to fill in the XXXX with the correct value. It does this until the entire program is parsed and the compiling is complete.
That's why it would be difficult to add the AxCalls before the data, I would have to change the 2nd pass to only fill in the AxCalls and then add a 3rd pass to only fill in the data and tack that on to the end of the program.
-
Ah right, I guess it's better to leave things as they are, then X.x. I wouldn't mind longer compiling personally, but on a regular 83+ it might be a bit too long x.x
-
Ah right, I guess it's better to leave things as they are, then X.x. I wouldn't mind longer compiling personally, but on a regular 83+ it might be a bit too long x.x
It's not long on a plain 83+ either, especially now that Axe actually quits right after compiling. But whichever's easier, Quigibo.
-
Well I stiill noticed some long compiling times sometimes on 83+. I assume with a 20 KB large game it might be insane while debugging x.x
-
maybe this could be changed for 1.0? it would definitely be worth any extra time.
then again, if it's too much work for you that's perfectly fine.
-
How bout its an option :) That way the user can decide. Hmm although that idea probably would take a crapload of extra code x.x
-
Yeah we don't want Axe to end up being like one entire page larger just because of this x.x
Maybe in the future there could be Axe Parser Lite and Axe Parser Full, though.
-
Yeah we don't want Axe to end up being like one entire page larger just because of this x.x
Maybe in the future there could be Axe Parser Lite and Axe Parser Full, though.
That might be hard to keep updated :P
Actually, it's not that important. I could just compile as an app.
-
Yeah that's the main issue x.x
It was hectic to update ROL series because there's a french and english version for each game.