83+ Quirk Discovered

Weregoose · Cemetech Expert Joined: 23 Oct 2009 Posts: 463

PROGRAM:A
:"<any two-byte token XX00>":prgmB:!

PROGRAM:B
:{0→u(nMin)

Run prgmA. I have no explanation for this. AFAIK, it works across all versions.
_________________
Common Errors in English · How To Ask Questions The Smart Way

elfprince13 · Posted: 06 Feb 2012 02:49:21 pm Post subject:

Just confirmed this on my 84+SE ROM in WabbitEmu. Weird - any theories?
_________________
StickFigure Graphic Productions || VSHI: Vermont Sustainable Heating Initiative

Aes_Sedia5 · Posted: 06 Feb 2012 03:33:19 pm Post subject:

What does it do?
_________________

Weregoose · Cemetech Expert Joined: 23 Oct 2009 Posts: 463

"{0→" coupled with that particular variable (or its v/w brethren) is the culprit; it appears to cause the interpreter to pop into the wrong location. I'd be happy if someone who is knowledgeable about the parser would take a look at this. Smile

_________________
Common Errors in English · How To Ask Questions The Smart Way

Deep Thought · Posted: 06 Feb 2012 07:14:36 pm Post subject:

It also works with any other paired delimiter (parentheses, braces, brackets) Shock

_________________

Weregoose · Cemetech Expert Joined: 23 Oct 2009 Posts: 463

Deep Thought · Posted: 06 Feb 2012 07:34:13 pm Post subject:

I meant the first line of prgmA. (Though I guess you already said that the problem is in the {0→u(nMin) line.)
_________________

Weregoose · Cemetech Expert Joined: 23 Oct 2009 Posts: 463

Well, replacing the second quote with anything but a quote will have the rest of the line served as a string, of course. But the point of the demonstration is that the second one of prgmA is being read twice. What ought to happen is that after the called program terminates, execution should resume at somewhere about the prgm token, but certainly not behind it. Let the next post please offer something insightful.
_________________
Common Errors in English · How To Ask Questions The Smart Way

thepenguin77 · New Member Joined: 09 Jun 2010 Posts: 79

I don't know what the actual cause is, but here's what I do know.

1. This glitch seems to restart the basic parser. It stops loops and removes all callback programs. (This could be a sweet hack)

2. The glitch blows 9 bytes in the FPS per use. I'm not sure where they are used, but I have pulled an Error:Memory using nothing but this glitch.

I'll try to look more into this later, but honestly, breaking For loops might have some serious uses. (Though I'm sure it wastes a lot of memory)

DrDnar · Member Joined: 05 Jan 2010 Posts: 108

How did you discover this bug?

Weregoose · Cemetech Expert Joined: 23 Oct 2009 Posts: 463

I legitimately wanted to use {0→u(nMin) in the middle of a program, and soon wondered why it wasn't letting me colon-chain any expressions past that prgm call on the homescreen, e.g., 1→X:prgmA0:Ans² wouldn't get to the Ans² despite the lack of a Return/Stop in the program. So that {0→u(nMin) could appear anywhere in prgmB, and the curio will persist as long as the interpreter is allowed to fall through the final line of the program [EDIT: or hits a Return beforehand].

Related:

BrandonW · Calculator Über-Deity Joined: 20 Sep 2006 Posts: 390

It's a bug in the BCALL _StoOther. It doesn't remove the value from the floating-point stack when you're storing to the following variables: u(nMin), v(nMin), w(nMin), Zu(nMin), Zv(nMin), and Zw(nMin). With the FPS messed up, subprograms and loops will behave very erratically afterward.

I have no idea why, but it's a serious bug and it's kind of amazing no one's ever found it before. TI should probably be told.
_________________