Speed of HP-49G Routine for Tektronix Vector Graphics Terminal

[3298]

Apologies for dragging this thread further off-topic, but I did an experiment to check how safe memory allocations from code in TEMPOB really are.
The code is designed to detect if it has been moved during execution. A pair of "checkpoints" (consisting of a GOSUB to a label just after it, followed by C=RSTK) are used to calculate the distance between two labels as they are encountered at runtime, then that distance is compared to the one calculated by the distance as calculated by the compiler. All this surrounds a call to PUSHhxs, since we've apparently chosen this call in our discussion as our favorite GC trigger.
The SysRPL program around the code deliberately sets up a low-memory condition, puts an HXS into TEMPOB followed by a copy of the code object. The HXS is then dropped to let the GC move the code object in order to make room for the code-pushed HXS, then the code is run. As a little cleanup the low-memory situation is cleaned up.
This program leaves the ASM-pushed HXS on the stack (different from the SysRPL-pushed one in its contents, by the way; that makes them easy to tell apart), and a SysRPL TRUE/FALSE flag telling me whether the code was moved in the middle of execution.

Code:

::
  ' CODE
    GOSBVL SAVPTR
    GOSUB label1
*label1
    C=RSTK
    R4=C.A ; the garbage collection documentation promises that it leaves R4 intact
    LA 123456789ABCDEF
    P=15
    GOSBVL PUSHhxs ; triggers GC, should ultimately succeed because another hxs could be cleaned up
    GOSUB label2
*label2
    C=RSTK
    A=R4.A
    C-A.A ; C.A is the distance between where the labels were encountered at runtime
    LA(5) label2-label1
    ?A#C.A ; is the distance different from the one calculated during compilation?
    GOYES end ; if yes, we were moved by the GC
*end
    GOVLNG "PushT/FLoop"
  ENDCODE
  GARBAGE (I want to control precisely how much memory is released in the next garbage collection)
  NULLHXS
  MEM
  3PICK OCRC DROP #- (subtract length of code object)
  BINT76 #- (leave enough room for the memory-eating hxs's object header and stack level, one more hxs and its stack level, plus some slack space for TEMPOB per-object overhead for them and the code object, but not enough for another hxs)
  EXPAND (does TOTEMPOB and in-place expansion)
  HXS 10 F0E1D2C3B4A59687 TOTEMPOB (needs 10 nibbles for prolog and size field, 16 nibbles for data, 5 nibbles for stack level)
  ROT TOTEMPOB (get the code object into TEMPOB after the hxs so the GC can affect it)
  SWAPDROP (drop the hxs to let the GC move stuff after it like the code object into its space)
  EVAL (run the ASM code)
  ROTDROP (drop the memory-eater, leave the code-pushed hxs and flag for inspection)
;

The program has a spot where the amount of memory left can be adjusted: it currently says BINT76. Very low values cause an "Insufficient memory" error, of course. High values permit the HXS to be pushed without the GC needing to run, so the results become the HXS and FALSE.
The interesting part is the range between these two. BINT119 seems to be the lowest value without GC interference; BINT118 does something very different - but it's not a crash from the last part of the code getting moved and in its original spot overwritten by the pushed HXS. It's the GC in "I'm suffocating" panic mode! This pauses the program to ask the user a number of questions about what shall be deleted (stack, last stack, last commands, various global variables and libraries in port 0, etc.) Letting it delete something obviously gives it room to breathe; answering "no" to all of them eventually goes up a directory and starts over, until it reaches HOME - the libraries in port 0 are last. After that it seems to just kill the program.

So, conclusion: the GC pins objects referenced by the Saturn RSTK and doesn't even move them. If that leaves it unable to do anything (memory allocation only happens after the last object in TEMPOB), it panics. Thus memory allocation from code in TEMPOB is safe.