Calling one axe program from another

[chattahippie]

So is there a way to easily (on calc) fix this, manually or auto?  Or does it require changing it on the computer?

[kindermoumoute]

To conclude, how to to fix it ?

[chattahippie]

On IRC, Runer suggested Zoom compiling the source, and it seems to work

[DrDnar]

I've got an epic solution and optimization for you all. I can both eliminate the problem with Copy( and reduce the code size by about ten bytes.

Code: Select All | Copy To Clipboard

1	"prgmNAME"Asm(E7EF7C4E

BAM! One-liner.
EDIT: This code causes a memory leak; see below for the fix.

For the curious:

Code: Select All | Copy To Clipboard

1 2 3

ld hl, ptrToName rst rMOV9TOOP1 bcall(_ExecutePrgm)

Also, to recap: The peep-hold optimizer is causing crashes with the Copy( command sometimes. You can stop Axe from doing the peep-hole optimization with ZOOM. However, it's all a moot point since I just replaced the Copy( command with the single assembly instruction rst rMOV9TOOP1.

[chattahippie]

I've got an epic solution and optimization for you all. I can both eliminate the problem with Copy( and reduce the code size by about ten bytes.

Code: Select All | Copy To Clipboard

1	"prgmNAME"Asm(E7EF7C4E

BAM! One-liner.

For curious:

Code: Select All | Copy To Clipboard

1 2 3

ld hl, ptrToName rst rMOV9TOOP1 bcall(_ExecutePrgm)

Also, to recap: The peep-hold optimizer is causing crashes with the Copy( command sometimes. You can stop Axe from doing the peep-hole optimization with ZOOM. However, it's all a moot point since I just replaced the Copy( command with the single assembly instruction rst rMOV9TOOP1.

Thanks for the fix

[Jonius7]

Could this somehow be added to the next version of Axe? Good thought for starting this topic, penguin77.

[kindermoumoute]

Damn, is work perfectly !

* kindermoumoute wonder if there is a way to start asm program compatible with shells...

[Quigibo]

Yeah sorry about that, I've fixed this problem but haven't released the update yet.

[chattahippie]

I think I found a bug with this... it causes my RAM to steadily decrease
I tried running both programs seperately, took out the "prgmNAME"Asm(E7EF7C4E) command, chose the same options on the menu (except no program was run from it), and no memory was lost

As you can see in the screenie, nothing was created, yet about 5000 bytes of memory disappeared (15000 at start to 10000 at finish)

[Yeong]

You can try this:

Type 1 in homescreen, press enter, and check memory again.

[chattahippie]

You can try this:

Type 1 in homescreen, press enter, and check memory again.

Tried that, it doesn't fix it
Still about 2000-2500 bytes lost per run

[DrDnar]

How are you quitting from the second program? It looks like the subprogram is quitting in a manner that prevents the memory being used by the caller from being freed.

[DrDnar]

Update: I blame thepenguin77's for this one. Looking at the disassembly of _ExecutePrgm, it's clear that the OS does not save the value in 89ECh (a.k.a. asm_prgm_size) before modifying it, so it turns out that the memory used by the caller will never be properly freed, unless you save it yourself. Fortunately, that's easy to do, so here's the new version:

Code: Select All | Copy To Clipboard

1	"prgmNAME"Asm(E72AEC89E5EF7C4EE122EC89

Edit: calc84maniac suggested rearranging the assembly instruction sequence to make it less ugly, though no smaller or faster.

So, once again, keep these points in mind:

• Just like running programs with the Asm( token from the homescreen, you need a quantity of free RAM equal to the size of the program being run.
• Because the OS has to shuffle RAM around for this to work, it takes a split second for the new program to start. So if you do this a lot, it'll be really slow.
• If you call yourself like this, the OS will make yet another copy of yourself. Duh.
• Instant quit will return control to the calling program, not the homescreen or the shell. This is because the error handlers get nested. (The good news is that if the calling program throws an OS error, control is returned to the calling program, but I don't believe any Axe programs use error handlers.)
• WARNING: This code will leak memory if the program throws an error! To prevent this, use the Axiom for running programs.
• By extension, do not call a shell's instant quit routine, or the memory used by caller won't get freed.
• Assuming Axe just makes a stub ISR that jumps to the real ISR, you're going to get a crash if you have an interrupt running and you try this, because your ISR just got moved.
• L1 through L6 will not be modified by the OS, neither during calling nor returning. The OP registers, however, will be corrupted.

OS Disassembly:

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92

OS 2.55MP _ExecutePrgm disassembly 07:5758: ld a, 03h call 3891h ld a, 38h jp nz, 2793h call 178Bh ex de, hl ld c, (hl) inc hl ld b, (hl) inc hl ld a, (hl) cp 0BBh jp nz, 2729h inc hl ld a, (hl) cp 6Dh jr nz, 57D4h inc hl push hl push bc pop de push de ld hl, 2000h or a sbc hl, de jp c, 2729h ex de, hl call 1735h pop hl push hl ld de, 9D95h call 0F81h pop hl ld (89ECh), hl pop hl ld de, 9D95h ld bc, (89ECh) add hl, bc ldir 579Fh: call 1837h jr nz, 57AEh in a, (20) push af bit 5, (iy+24h) call 0DCBh 57AEh: ld hl, 5800h call 27DAh call 57FDh call 2800h call 1837h jr nz, 57C4h pop af and 01 out (20), a 57C4h: ld de, (89ECh) ld hl, 0000h ld (89ECh), hl ld hl, 9D95h jp 1368h 57D4h: rst 18h ;rPUSHREALO1 call 5717h ld hl, 2000h or a sbc hl, de jp c, 2729h ex de, hl push hl call 1735h pop hl push hl ld de, 9D95h call 0F81h pop hl ld (89ECh), hl call 150Fh ld de, 9D95h call 5734h jr 579Fh 57FDh: jp 9D95h 5800h: call 1837h jr nz, 580Ah pop af and 01 out (20), a 580Ah: ld de, (89ECh) ld hl, 0000h ld (89ECh), hl ld hl, 9D95h call 1368h jp 2799h