somehow, the addition of SHMF?SHMF/256=Q?SHM xor 1->SHM
before and after an if statement makes the if statement not work when SHM=1. This is a bug w/peephole ops, as it works perfectly when I zoom through it.

Edit:fixed a typo.(phone keyboard) The erroneous SHMPE has now been replaced with the correct SHM=1

I found the bug with peephole opts a while ago which happens in extremely rare cases when you use a data offset in your code followed or preceded by an actual constant that has the same value as the offset and they happen to be in a pattern that can peephole optimize.  An example of where I saw this was during a GetCalc(Str1,6) where the start of Str1 was the 6th byte of data and Axe erroneously optimized it to GetCalc(Str1,).  Adding junk data to the beginning such as Buff(1) or some other small number which pushes the offset is a temporarily workaround, or simply zooming.

What you're reporting though doesn't sound like that.  Are you sure that's what's causing it?

Found the bug! The peephole optimizer normally works by simply examining the compiled code, which is fine and dandy for 99.9% of code. But if a potential jump point exists inside of the code that the peephole optimizer is trying to optimize, the optimization should not be performed. I see that Quigibo remembered this and coded an abort to optimizing if an End of an if statement or a Lbl is inside the matching code, but no such abort exists if the previous line ends in an inline conditional. However, this is effectively like the End of an if statement, and should not be optimized. This lapse may exist because Quigibo forgot about this case, or perhaps just because it's probably more of a pain to detect.

They're variables like any other variables, except they were intended to be used to interface with Axioms. But you don't have to use them for that, as Freyaday is probably doing.

Ah yes, I did forget about this case.  Fixed.

I got some really weird bugs when I compiled nymless into an app on a pair of 83+s:
on one, it didn't even show up after it finished compiling and I had to compile it again. Then, on both of them, in the os, table entries showed up on the graph screen, and the plot selections didn't show up in the Y= screen. The one I had to compile twice on got fixed by, iirc, a garbage collect, and the other calc was fixed with a ram clear.

Bug report: ⁻{L1+9}^r is compiled as {⁻L1+9}^r.

EDIT:

[21:02:28]   Runer112   it also happens with one-byte variable reads
[21:02:48]   Runer112   but the address has to be a constant

Code: [Select]

:.TEST
:[FFFFFFFFFFFFFFFF]->Str1
:0->{L1}
:0->A
:Pt-on(8,8,8*{L1+A}+Str1
:DispGraph
This gives the "Wrong # of Args" err. Is this a bug, or am I just stupid?

Yes, this is a bug:

Quote from: Builderboy on October 03, 2011, 06:08:55 pm

{CONST} or {CONST + Var} produces a 'Wrong # of Args' error

Thanks, I just caught that.  A workaround for now is to just add the constant after the variable: Var + CONST, which is more optimized anyway.