(42S) A challenge of a different kind

[Werner]

Background:

Run the following little program:

01 LBL "T"
02 LBL 02
03 XEQ 00
04 GTO 02
05 LBL 00
06 GTO 10
00 <filler bytes>
00 LBL 10
00 END

Place anything at all as filler bytes, they are not executed anyway.
Observe the flying goose: it runs around the display very quickly, unless the total size of the filler bytes exceeds 127 bytes, then it will run markedly slower.
This is the 'compiled GTO' in action: the distance to the corresponding LBL is recorded in the GTO itself, the first time it is executed. For 2-byte GTOs, this distance is encoded with 8 bits, one for the jump direction, and 7 bits for the distance. So, jumps of 127 bytes forward and backward can be encoded. If the distance is larger than that, the 42S has to conduct the search for the label each and every time, slowing down execution.

 GTO 10
 <max 127 bytes>
*LBL 10
 <max 124 bytes>
 GTO 10

For backward jumps, the LBL and GTO itself are part of the 'distance'.

The same holds for 3-byte GTOs, but there, the distance is encoded in 13 bits, or a maximum of 4095 bytes forward and 4090 bytes backward. A 42S can hold a program larger than this, so we can test this out, now with a 2-byte LBL:

01 LBL "T"
02 LBL 02
03 XEQ 00
04 GTO 02
05 LBL 00
06 GTO 20
00 <filler bytes>
00 LBL 20
00 END

And here comes the challenge: enter 4095 filler bytes in as few keystrokes as possible.. we do not want to brick our 42S's keyboard.

Assume an empty machine with the above program in it, no filler bytes, and the program counter on line 06 GTO 20.

examples:
- Press X<>Y 4095 times, your score is 4095
- Press
shift
MATRIX
DET (2046 times)
X<>Y
for a score of 2049

so, what is the best you can do?

additional remarks:
- in the case of the short GTO, you will need a substantial number of program *lines* between the LBL and GTO to see the slowdown. If you just put eg. 10 14-byte alpha strings there, the difference in goose speed is negligible.
- the 42S User's Guide on page 149 in the footnote mentions maximum distances of 128 and 4096 bytes for short and long jumps, respectively. You can now verify for yourself that this should be 127 and 4095 bytes.
- keep in mind that LBL and GTO are included in backward jumps.
- in the 41C the count is different as it uses a combined register and byte count, and there the limits are 112 and 3584 bytes, respectively
- in case you are wondering: yes, I actually did this on my 42S ;-)

Cheers, Werner

[J-F Garnier]

(01-19-2024 10:30 AM)Werner Wrote:  And here comes the challenge: enter 4095 filler bytes in as few keystrokes as possible.. we do not want to brick our 42S's keyboard.

That's a uncommon but real-case challenge !

My take:

enter (or press) in PRGM mode:
LBL "ABCDEFG"
CATALOG
CATALOG (twice, to make it permanent)
PGM soft key
then repeatedly press "ABCDE" soft key to enter XEQ "ABCDEFG", consuming 9 bytes each time.
So score is about 455 keystrokes.

J-F

[Werner]

(01-19-2024 01:14 PM)J-F Garnier Wrote:  enter (or press) in PRGM mode:
LBL "ABCDEFG"
CATALOG
CATALOG (twice, to make it permanent)
PGM soft key
then repeatedly press "ABCDE" soft key to enter XEQ "ABCDEFG", consuming 9 bytes each time.
So score is about 455 keystrokes.

J-F

Close ;-) But the count is not correct of course, the definition of the LBL also has to be taken into account, including shifts, and you have to insert exactly 4095 bytes ;-)
Werner

[Werner]

So, J-F had the right idea, of course. Define a 7-character LBL and insert XEQ ".." using the catalog, effectively entering 9 bytes with each keypress. You can't do better than that, to my knowledge.
He did, however, use LBL "ABCDEFG", which requires 18 keypresses, while eg LBL ".123456" only requires 11.
Entering the line XEQ ".123456" 453 times, you have then entered 11 + 453*9 = 4088 bytes in total, 469 keypresses so far, and 7 bytes left to enter.
I can enter these 7 bytes with only three keypresses, in two different ways, even. Can you?

Werner

[Paul Dale]

Is using the hex editor and entering stuff directly competitive?

[Werner]

Mh I'd say you can only change a single nibble at a time with the hex editor, no?
Werner