The life of flash memory decreases with archive sector erases, not archive writes. Each sector is 64KB large. If you consistently unarchived and archived variables, each 64KB written to archive would result in one erase of the swap sector (probably the first sector likely to fail) at the next garbage collect. It is very roughly estimated that sectors may be likely to fail starting around 100,000 erases, so a total of about 6GB (yes, gigabytes) would need to be archived in the calculator's lifetime to start worrying about the flash memory failing.

Endif == true => continue ( directly go to loop begin)
Endif == false => break; ( stop the loop).

(It's what I understood from Runner)

You know how I said EndIf is a confusing command? Well I got my description of the cases backwards... Oops

But you have the idea right. Your post describes exactly how the companion command End!If works. I've edited my original post to correct my mistake.

Unfortunately, Axe doesn't currently support continue or break statements. Fortunately, it supports gotos, which can be used to manually implement the break behavior (except in single-argument for loops) like this:


For(A,1,10)
.stuff
Goto Break
.stuff
End
Lbl Break



Continue can be implemented by simply moving the label up a line. And yes, this is the right board for the question.

I found out that parsingPtrs is not safe the hard way. It took me a good hour or so to debug that overwriting basic_start, nextParseByte, and possibly basic_end causes errors to be thrown when the program exits, despite the program not being a BASIC program.

I get it on compiling every program.

Sometimes it happens when I just quitted a Asm program.

But I can't explain more: I just get more often Unknown Error with zStart than normally. You should backup program before compiling.

I think I got a pointer to these unknown errors: I think that's related to RAM allocation for programs. Trying to compile two time a 16kb program made Axe crashed.

I'm fairly confident that the primary culprit of unknown compilation errors has been fixed for the next version of Axe, as well as the general freezing of error messages. The unknown errors would crop up more often when compiling large archived source files, a case which you seem to fit. For now, the only possible fix I can offer is to unarchive and rearchive programs that cause unknown errors.

I don't understand how you could get an unknown compilation error from Axe when exiting an assembly program, though, considering Axe shouldn't even be running any more.

Idea, that would be REALLY great :
Nested libs. I had an idea, it's : 1st pass, compile and replace all prgmLIBSNAME by its commands, and if, at the 2nd pass, you find another prgmNESTLIB, then repeat 2nd pass ; end program compilation when there's no more lib to add.
But if someone creates a lib that includes itself ?

I do agree that fully supporting nested includes/libraries would be nice. Support for at least a few more nesting levels could possibly be added. Approximately what maximum level of nesting do you believe would be reasonable?

And if a library included itself, it would just keep including itself until an error occurs, whether it be due to the maximum nesting level being reached, RAM having been filled by the compiled program, or just duplicate definitions.

Hi, I'm not sure if this is a bug, but the command ->HEX seems to always point to the string "11" when used with axe fusion. Could you look into it? Thanks.

You are indeed correct. I don't actually remember doing this and I didn't record it in the changelog, but apparently I've already fixed this in my development version. So it'll be fixed in the next release. Until then, I guess don't use Axe Fusion if possible. Unfortunately, the system is still experimental and not super reliable, so issues like this seem to be common with it.

Activating zStart makes compiling like a russain roulette: you get a freezing unknown error with a 1/2odd.

Lastest version of Axe&zStart on a 2.43 84+

Can you elaborate? The frozen unknown error in Axe 1.2.1 is a known bug and should be fixed in the next version, but I can't quite understand the situation you're describing that led to it.

Yeah I noticed that but it's rare enough to make it acceptable, nut still annoying.
There's another issue : when compiling from Axe, the Goto function messes stuff up and leaks all your RAM so you have to RAM clear.

You mean scrolling to errors? Are you using an old version of zStart? I forgot to mention it in the changelog, but Axe 1.2.1+ now checks if zStart exists, and if so, uses its instant goto function for going to errors instead of Axe's. Unfortunately, the API instant goto function was broken in some older versions of zStart, but there's no way for Axe to easily know what version it is so Axe will blindly use the broken API function in older versions of zStart.