Well, with new stack commands, wouldn't it be possible to exit from a subroutine like this?

Code: [Select]

Lbl EXT
π -> A
Return
That should pop the address of the call to the routine, and then return like a normal program exit.  Correct me if I am mistaken.

Though this would not work in flash apps.

Because the OS return location is dug into the stack at an unknown depth, you cannot access it. The solution to this is to backup the OS return location at the start of your program when you know that it is the topmost stack entry. I would suggest using code like the following:

Code: [Select]

.MYPROG

Asm(ED73E383)          .Back up the OS return location

.YOUR PROGRAM GOES HERE

Asm(ED7BE383ED56C9)    .Exit program from anywhere, put this wherever you want it


---

EDIT: Quigibo, perhaps you could add a Return^r function for this? I could be wrong, but I believe I see a very easy way to handle this. If a Return^r is detected in the first pass, set a flag to say so, but otherwise parse the Return^r command and the rest of the pass as normal. Before starting the second pass but after the header has been added, check this flag. If it isn't set, resume as normal. If it is set, add the 4-byte stack pointer backup code to the beginning of the program and then step through every static pointer, increasing them by 4. The rest of the program should then be able to be parsed normally.

This reminds me, would the new stack commands conflict with operations that implicitly use the stack? For example, A->π B-(π+C) would in theory compile to something like:

Code: [Select]

ld hl,(axv_A)
push hl
ld hl,(axv_B)
push hl
pop hl
ld de,(axv_C)
add hl,de
pop de
ex de,hl
or a
sbc hl,de
Long story short, the pops would happen in the wrong order. How will this be handled?

Here's a slightly easier way that might be less compatible with shells:

Code: [Select]

Asm(2ADE86 2B 2B F9 C9)You don't need to place any special code at the start of the program.

It uses the fact that the OS (and probably all shells) always wraps programs in an error handler when it runs them. So if any shells don't do that, or place any extra pushes on the stack before running the program, it'll crash. But all shells have to use an error handler, or else an error will quit the shell itself.

Spoiler For Actual assembly code:

Code: [Select]

ld hl, (86DEh) ; This address is how the OS always knows how to restore the stack with APP_POP_ERR
dec hl
dec hl
ld sp, hl
ret

Quote from: Scout on April 13, 2011, 08:43:16 am

Also Quigibo, what about including in Axe commands a list of the Asm(HEX commands that may be useful for Axe programmers?

You (plural) should make Wiki for that. WikiTI might work, if you don't feel like setting up a separate one.

By the way, the code I posted earlier is based on my disassembly of the code that runs programs. It's definitely not something you're likely to come up with just by reading the SDK.