Easy as { 1 2 3 }? (when { 1 2 3 } ≠ { 1 2 3 })

[DavidM]

(07-15-2018 04:12 AM)Joe Horn Wrote:  Uh oh... I just took a peek, and I wish you luck. None of those commands have a dispatch for the integer type, and for reals they do a NOP. So the "normalization" must be done by the dispatch code (not in the S Series but added in the G Series), specifically the code which handles integers when no integer dispatch exists. I've never delved that deeply into the ROM.

I've already started looking at SIMPLIFY. In that particular case, there's a dispatch for BINT10 (hex A), which is "Symbolic class". This is where the long-form ZINT ends up branching. Unfortunately, it looks like the way this ends up getting handled is to pass the zint to CASEVAL, which in turn passes it to CASCOMPEVAL, and from there I'm starting to get a headache trying to trace what happens. This is nothing new, it seems to happen every time I start trying to trace something that branches into a CAS handler.

I did some experiments with a short SysRPL routine that simply passed all zints to CASEVAL, and ended up with run times similar to the →STR STR→ methods. So at the moment it's looking like my choices are:

1) Drive myself crazy trying to trace through the various CAS handlers until I find something that will be highly-specific to a rev. 2.15 ROM (and perhaps still not be directly applicable to a separate routine like I need).

2) Use →STR STR→ and put up with the wait.

3) Spend a bit more time optimizing the existing code I already have and grudgingly accept the memory footprint in return for the performance.

I'm leaning toward #3 at present.

While I was at it, I looked a bit more closely at the handlers for reals and noticed why everything I've tried already does the substitutions for those: it conveniently occurs in the PUSH% code, which is ultimately what most everything calls when placing a real on the stack (either directly or indirectly). That's why this issue seems to be isolated to exact integers.