ML decomp and Eqstk for HP48GX

[rs1n]

Hi everyone,

I spent a few days searching comp.sys.hp48 for bugs relating to the ML
decomp (which can be found in Java). Have all the ML decomp bugs been
found and fixed (namely the one having to do with arrays)?

I also managed to dig up an old post on Java being somewhat slower in
displaying algebraic objects than Eqstk even though it is the same
code. I tested this with Java 3.7b and Eqstk 9.1 using the examples in
the EXAMPLES directory created by the TEACH command. Type TEACH and go
to { HOME EXAMPLES EQNS } and place RATFUNC onto the stack. Compare
the rendering times for Java and for Eqstk -- there's a huge
difference! Having looked at the Java code, I cannot figure out why
the rendering time is slower. Java even ensures that algebraic
rendering gets priority (display/stackdsp.s).

Java's source code mentions Eqstk 9.2 (though I have not seen Eqstk
9.2) got updated to include doing CRC checks within the cache. Is it
possible the CRC check is the cause of the difference in rendering
times? (see cache/cache.s) On the other hand, the CRC routines are in
ML and are short -- and in the example above, we're talking only one,
single, algebraic object.

[rs1n]

I believe I may have found the culprit as to why Java can be slower
than EQSTK for rendering symbolics. While the code is _almost_ the
same, Java's source alters AGrob so that as much of the decompilation
is done with the ML decomp routine as possible. The problem is here:

NULLNAME MLa%>$
::
ONE SYMBN ML>STR ( embed in symbolic and decomp )
DUPLEN$ TWO SWAP #1-SUB$ ( strip off quotes )
;

In Java's source, ra%>$ (found in agrob/agrob.s) is defined as MLa%>$.
What I personally don't understand is why the real number needs to be
embedded into a symbolic -- is there a case when a real number appears
differently all on its own vs. being inside a symbolic? If not, why
embed into a symbolic when ML>STR is just as capable of handling real
numbers? And lastly, is ML>STR faster at decompiling real numbers than
the built-in a%>$?

Now for why Java is slow at rendering: imagine a symbolic with many
real numbers. Every time a real number is encountered (which is likely
often), it is slowed down by this kludge of a routine. AGrob explodes
all symbolics and parses each object within. There is a huge amount of
overhead per real number as a result. The fix is of course to just
revert back to a%>$ or find a more direct way of decompiling real
numbers with better calls to the ML decomp routines.

If Raymond is reading this post -- even SpeedUI is affected by this
kludge (see ROMPTR 325 BC -- this is the last NULLNAME within UI.LIB)