Bug Reports

[Yeong]

This happened again: Axe have a bug with generating appvar O.o
It gives me ERR:MEMORY even though appvar is only 48 bytes big O.o

[ztrumpet]

That doesn't sound like Axe is the one at fault.  Can you please post your code for doing this?

[Yeong]

Data(0,0,0,0,0,0,0,0,0,......)->A
GetCalc("appvMTEMP",48)->B
Copy(A,B,48

[Happybobjr]

change a to gdb1 plz and post results

[Runer112]

Axe has problems when the last of the compiled code in a program is targeted by the peephole optimizer. In this case, Axe is producing erroneous code because Copy(A,B,48 is the last bit of code in the program and it's targeted by the peephole optimizer. This can be avoided easily enough until it is fixed by putting some other code after it or turning off the peephole optimizer altogether by pressing ZOOM to compile instead of ENTER.

[Yeong]

still gives me an ERR:MEMORY.

EDIT: I had 19545 RAM left, fyi

[Quigibo]

I know exactly what is causing that error.  It is as runner said, the peephole optimizer.  There is currently a bug where Axe confuses offsets with constants and is turning your code into exactly this:

Code: Select All | Copy To Clipboard

1 2 3

Data(0,0,0,0,0,0,0,0,0,......)->A GetCalc("appvMTEMP",)->B Copy(A,B,48

The current offset in the code is 48 and you were using 48 at the same time to specify the size.  It also happens to be in a pattern that normally peephole optimizes.  So now its attempting to create an appvar with a size equal to the pointer which is a number around $9E00 which is over 40,000 bytes!  You can fix this temporarily as Runer said by using zoom compile or adding one more zero to your data.  Adding more code to the end wouldn't fix anything because there aren't any known bugs with ending code changing behavior to my knowledge.

[Yeong]

ah, thank you so much for clearing that out for me.

[Runer112]

I know exactly what is causing that error.  It is as runner said, the peephole optimizer.  There is currently a bug where Axe confuses offsets with constants and is turning your code into exactly this:

Code: Select All | Copy To Clipboard

1 2 3

Data(0,0,0,0,0,0,0,0,0,......)->A GetCalc("appvMTEMP",)->B Copy(A,B,48

The current offset in the code is 48 and you were using 48 at the same time to specify the size.  It also happens to be in a pattern that normally peephole optimizes.  So now its attempting to create an appvar with a size equal to the pointer which is a number around $9E00 which is over 40,000 bytes!  You can fix this temporarily as Runer said by using zoom compile or adding one more zero to your data.  Adding more code to the end wouldn't fix anything because there aren't any known bugs with ending code changing behavior to my knowledge.

Uhh... I don't think that explains the code I'm looking at:

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

ld hl,Data000 ld (axv_A),hl ld hl,Data001 push hl ld hl,48 ;I'm still here call p_NewVar ld (axv_B),hl ld hl,(axv_A) push hl ld hl,(axv_B) push hl ld hl,48 pop de ;Note the abrupt end p_NewVar: B_CALL(_EnoughMem) pop hl ex (sp),hl jr c,__NewVarFail push de push hl MOV9TOOP1() B_CALL(_ChkFindSym) jr c,__NewVarSkip B_CALL(_DelVarArc) __NewVarSkip: pop hl ld a,(hl) MOV9TOOP1() pop hl push af B_CALL(_CreateVar) pop af ex de,hl and %00011111 ret z cp CplxObj ret z inc hl inc hl ret __NewVarFail: ld hl,0 ret __NewVarEnd: Data000: .block 48 Data001: .db AppVarObj,"MTEMP",0

[Quigibo]

That's because the 2 passes get out of sync since it did the replacement in the first pass but didn't in the 2nd.  That can result in all kinds of crazy stuff.

[Runer112]

Ah, I guess that could do it. A very crazy bug indeed.

[TeruFSX]

There appears to be a bug where certain for-output combinations go and corrupt a bunch of memory.

I tried to do this:

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8 9 10

0->I For(I,1,8) rand^16->{I+L1} End 0->I For(I,1,8) Output({I+L1},I,"*") End Pause 5000

It ran fine, but upon returning to the home screen it filled with garbage. Free RAM hit 0.
EDIT: Does output use 16-bit ints?

[jacobly]

For the output command, the column is in the range 0-15 and the row is in the range 0-7.
In your code, I ranges from 1 to 8, so everywhere you have I, you need I-1 (unless you want to use {L₁+0} for something else).

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8

For(I,1,8) rand^16→{I-1+L₁} End For(I,1,8) Output({I-1+L₁},I-1,"∗") End Pause 5000

Edit:
The fact that you have 0→I before For(I,1,8) makes me think that you are trying to make I range from 0 to 7. However, For(I,1,8) starts off by storing 1 to I, causing the 0→I statement to be useless. Instead you may want For(I,0,7).

[Darl181]

I know exactly what is causing that error.  It is as runner said, the peephole optimizer.  There is currently a bug where Axe confuses offsets with constants and is turning your code into exactly this:

Code: Select All | Copy To Clipboard

1 2 3

Data(0,0,0,0,0,0,0,0,0,......)->A GetCalc("appvMTEMP",)->B Copy(A,B,48

The current offset in the code is 48 and you were using 48 at the same time to specify the size.  It also happens to be in a pattern that normally peephole optimizes.  So now its attempting to create an appvar with a size equal to the pointer which is a number around $9E00 which is over 40,000 bytes!  You can fix this temporarily as Runer said by using zoom compile or adding one more zero to your data.  Adding more code to the end wouldn't fix anything because there aren't any known bugs with ending code changing behavior to my knowledge.

Aha, so this must be why the Essence editor truncates randomly...
Good to hear that it's found tho

[ztrumpet]

According to this, Axe uses some SMC.  I think it's probably the programmer's fault, but I figured I'd post this here so it could be looked into.