SamCoVT / TaliForth2

A Subroutine Threaded Code (STC) ANSI-like Forth for the 65c02
Other
29 stars 5 forks source link

faster, smaller backslash translations #43

Closed patricksurry closed 5 months ago

patricksurry commented 6 months ago

Switching to a translation table for \a-z saves about fifty bytes and a bunch of cycles when processing strings. All tests pass, and broke spectacularly when I had an error so the code is definitely exercised.

You see the effect in test cycle output for number and >number even for very short strings.

patricksurry commented 6 months ago

one question. The original code mentioned \n was implementation dependent, but always just outputs LF.

My new code works the same, but wondered if the original intention that this should respect TALI_OPTION_CR_EOL ? This would be easy change via some conditional assembly in the translation table.

_check_esc_n:
                cmp #'n'
                bne _check_esc_q

                ; newline, impl. dependant, using LF (ASCII values 10)
                lda #10
                bra _save_character
SamCoVT commented 6 months ago

I'm always a fan of saving bytes, and I didn't even consider a table here because the elements to replace were non-contiguous. I should have time to look at this and merge this sometime this weekend.

I do agree that \n probably should follow the line endings from the TALI_OPTION_CR_EOL (it would make TYPEing this string follow the user's line ending), although it has the annoyance of resulting in different string lengths and will will only be tested with the LF line ending setting (which is what platform-py65mon.asm sets), so we'll want to test it manually to make sure it's working properly for the three expected settings (just LF, just CR, and both CR and LF (in CRLF order))

If you don't get to it before me, I can add that functionality - you'll still end up saving bytes in the long run as that will be mostly handled with conditional assembly. You can look at xt_cr: in native_words.asm to see how I handled it there, but I don't think that fits your exact case here because it looks like you need to fall into the code that compiles the character with the char in A. You'll need one of: Put CR in A Put LF in A Put CR in A, compile it, then put LF in A. I think that can all be handled with some conditional assembly checks - and I agree that you'll need to add a special handler for \n.

patricksurry commented 5 months ago

The table can already handle each of the options so I just conditionally decide which byte to put in the table. I tested all three cases with s\" n\nm\ml\lr\r" dump as well as re-running the tests for the default case. There was a comma missing in the commented out CRLF config.