We're saying #Realloc() already serves another purpose. It's used to relocate the A-θ vars to another address. For instance, #Realloc()^r and #Realloc()^rr would probably work.

I've talked to Runer112 about it some time ago, and he said the PC was very hackish in the Axe compiler, so adding those features is very unlikely to happen before Axe 2.0.

Sorry for the lack of responding. I was both physically and somewhat mentally ill for a while, so I ceased basically all activities outside of eating, sleeping, and entertainment. Anyways...


In response to changing the code origin, as you guys have correctly figured out, Axe does indeed calculate PC directly from the offset in the compiled program. Making this user-controllable would probably be tricky from an implementation standpoint. There's also the important goal that I'd like to see Axe become higher-level over time rather than lower-level, an adding manual code origin control is quite contrary to this.

That's not to say this capability cannot be added, though. Since the theoretical Axe 2.0 looks a lot like C in my head, it should support functions. Both function and data definitions could support keywords or something similar that specify origin, which I believe would provide the functionality needed for most uses in a pseudo high-level fashion.

Something else : as using the ^r modifier on a variable only use its first byte, we could be able to do For(VAR^r,MIN,MAX) (or designed another way, probably better : For(VAR,MIN,MAX)^r). Maybe also do the same for big-endian, with ^rr.

I've imagined the code for a for loop with a one-byte variable in my head for a bit now and am of the opinion that the general result would probably be larger than a for loop using a two-byte variable. The problem is that Axe has to evaluate the minimum and maximums as two-byte values in HL because that's the only way it knows how to evaluate arbitrary expressions, so the potential savings of using a one-byte value and arithmetic are killed by the conversions between one- and two-byte values. (Side note: it may seem like the For(EXPR)^r command has no reason to exist for similar reasons, but the difference is that once the two-byte value is converted to a one-byte value at the start, all following operations are one-byte only)

If both the minimum and maximum were constants, then all the logic could certainly be coded in smaller one-byte operations. But in the case that the compiler is special-casing for loops with constant bounds anyways, there's little point for the alternate one-byte syntax because it could automatically check if both constants are one-byte values and, if so, use one-byte operations.

That should definitely exist, yes. I can't really remember why it doesn't... I guess I can try it at some point.

Sorry to hear about the health issues Runer112. I hope nothing too bad (socially or physically) happened that caused this.

Oh, I didn't pay attention to the beginning of his message ! Runer112, I hope you're better now.

Here's another idea of feature to add to Axe Parser : when it doesn't find a library, it could search for it in groups. That'd be great for people who have a lot of libraries and don't want them to be shown in the program list, or when they're working on a single program from a big project split in multiple programs. Both are often my case  !

I am unsure if those are really Axe issues, because they are present in ASM too if you aren't exiting from your programs properly, not to mention that some people use such program as sub-routines and might not be willing to see the program clear the graph screen background image for them. I think that for that reason, it is generally assumed that it's the programmer's job to prevent such issues from happening.

I think that making the program require a shell usually helps in certain situations, though.

Oh I meant that DCS and Mirage erases the game graphics  from the screen upon exiting.

That command definitely makes sense to add. The only thing I'd think about is if there's potentially a token that makes more sense, but none spring to mind.