0 Members and 4 Guests are viewing this topic.
Well, with new stack commands, wouldn't it be possible to exit from a subroutine like this?Code: [Select]Lbl EXTπ -> AReturnThat 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.
Lbl EXTπ -> AReturn
ld hl,(axv_A)push hlld hl,(axv_B)push hlpop hlld de,(axv_C)add hl,depop deex de,hlor asbc hl,de
In other news, Frey continues kicking unprecedented levels of ass.
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].MYPROGAsm(ED73E383) .Back up the OS return location.YOUR PROGRAM GOES HEREAsm(ED7BE383ED56C9) .Exit program from anywhere, put this wherever you want itEDIT: Quigibo, perhaps you could add a Returnr function for this? I could be wrong, but I believe I see a very easy way to handle this. If a Returnr is detected in the first pass, set a flag to say so, but otherwise parse the Returnr 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.
.MYPROGAsm(ED73E383) .Back up the OS return location.YOUR PROGRAM GOES HEREAsm(ED7BE383ED56C9) .Exit program from anywhere, put this wherever you want it
Asm(2ADE86 2B 2B F9 C9)
ld hl, (86DEh) ; This address is how the OS always knows how to restore the stack with APP_POP_ERRdec hldec hlld sp, hlret
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 hlld hl,(axv_B)push hlpop hlld de,(axv_C)add hl,depop deex de,hlor asbc hl,deLong 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_ERRdec hldec hlld sp, hlret
Also Quigibo, what about including in Axe commands a list of the Asm(HEX commands that may be useful for Axe programmers?
Quote from: Scout on April 13, 2011, 08:43:16 amAlso 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.