Axe Q&A

[Hayleia]

but I can see how the second one would be useful for saving space in the source program.

Not only. In fact, I have I am declaring a sequel of pointers. And in case I forgot to declare one, I would just need to insert a +1→°Var2 between the Var1 and the Var3. Same if I finally want to change the order of my pointers but still want them to be right next to each other.

Maybe you should take that on over to the Features Wishlist.

Done

[Hayleia]

Does compiling happen at 15 MHz for capable models or is it always at 6 MHz ?

[Deep Thought]

Yes, Axe uses 15 MHz when it's available.

[Hayleia]

Does the fnInt(LBL,FREQ) function first disable all interrupts before enabling the LBL interrupt ?

If no, what should I do to support several enabled interrupts (if possible) ?

[nikitouzz]

there will be a new version of the axis or 1.1.2 final is the one?

[squidgetx]

Hayleia, (lol this question is from sept), I'm pretty sure you can only have one interrupt on at a time.

Nikitouzz, Runer112 is working on a new patched/optimized version of Axe. If he ever finishes it, there might be an update (or if Quigibo comes back =/)

[Eiyeron]

Could we get Axe speedier?

[Runer112]

Could we get Axe speedier?

Do you mean speed of compiled programs, which can now be improved with the #ExprOn directive I just added with Axe 1.2.0? Or do you mean the compiling process? Because I think to speed up the compiler, it will more or less have to be entirely rewritten, which is a large task. That's not to say that I don't plan on doing it, it would probably just take a fair bit of time.

[shmibs]

* shmibs thinks that the compiler itself is plenty fast enough as it is, and that time would be better spent elsewhere.

even when constantly compiling apps, the speed isn't really an annoyance

[squidgetx]

I still say that drawing the progress bar does something to make the compiler slower (and that it would be nice to have an option to disable it)...Quigibo rejected that thought last time I brought it up saying it takes no more time than displaying the percent progress. But that doesn't mean that it doesn't slow it down though, amiright? It still takes up time to draw the thing. (and I feel like the compiler was noticeably speedier before the progress bar's introduction)

[Builderboy]

Squidgetx it is true that it does slow it down a small amount, but I imagine Quigibo didn't implement disabling it because it would barely make a difference even in some of the longest of compiles.  My guess is that even if you were compiling for a full app, it wouldn't even add a second of compile time, although Runer will have to report back.

[Deep Thought]

For me at least, what made Axe seem considerably slower when the progress bar was introduced is the new lag-time between hitting ENTER and the screen updating (in the compile menu), which wasn't there before.

On the other hand, it did seem to compile slower than before (I'm on a TI-83 Plus so it's a lot easier to notice).

[shmibs]

well, there were a lot of other things added around the same time, so the compiler itself increasing in complexity could probably account for the majority of the slowdown.

[Freyaday]

Well, I know of one display increase that could be implemented: The Numbers for Size continue to update after the first pass.
The size of the program doesn't change after the first pass.

[133794m3r]

I heard that Axe uses the last 54bytes of L1 for the A-Z+Theta variables for programs? Is this true? Also how volatile is the L2? It says "low", but, if I'm storing some data in it, it should be safe during the execution of the subroutine right? The whole reason I'm even thinking about using L2 is because of that thing I heard about the last54bytes of L1. I need 768bytes of ram in total for my range encoder(256 for the symbols,512 for the counters), but that's just the "maximum", it could be less than that. But, I don't want to needlessly fill some variables and take up even more ram(already looking at 2-3k at the peak...), so even more ram used seems kinda crazy to me... I'd like to use "safe/free" ram instead of the available ram for the program, as I expect(hope) that people will use the range encoder/decoder for their data compression needs.