inline literals and two-literals, faster non-native two-literals

[patricksurry]

Adds support for inline literals (and two-literals) which are much faster than the jsr + payload version. Inline literals require 6 bytes for byte-sized values and 8 bytes otherwise. Doubles take twice the space so the default nc-limit of 20 inlines both single and double values.

When 2literal is non-native it now shares sliteral_runtime using jsr ... with a four byte payload rather than two jsr each with two byte payload, which makes it more compact and almost twice as fast.

One minor issue is that disasm now shows both non-native string literals and doubles as SLITERAL (see below). It might be possible to use the presence/absence of the preceding jmp over-string to decide whether to show SLITERAL or DLITERAL, and could then use d. to show the constant instead of u. . like SLITERAL does. I was also wondering whether the jmp over-string in diasm should show the first 48ish characters of the string value alongside. wdyt?

: foo 42 1234 12345678. ; see foo 
...
size (decimal): 36 

08E0  A9 2A CA CA 95 00 74 01  A0 04 A9 D2 CA CA 95 00  .*....t. ........
08F0  94 01 A0 61 A9 4E CA CA  95 00 94 01 A9 BC CA CA  ...a.N.. ........
0900  95 00 74 01  ..t.

8E0     2A lda.#
8E2        dex
8E3        dex
8E4      0 sta.zx
8E6      1 stz.zx
8E8      4 ldy.#
8EA     D2 lda.#
8EC        dex
8ED        dex
8EE      0 sta.zx
8F0      1 sty.zx
8F2     61 ldy.#
8F4     4E lda.#
8F6        dex
8F7        dex
8F8      0 sta.zx
8FA      1 sty.zx
8FC     BC lda.#
8FE        dex
8FF        dex
900      0 sta.zx
902      1 stz.zx
 ok

15 nc-limit !  ok
: foo 12345678. ; see foo 
...
size (decimal): 7 

0883  20 BC A1 4E 61 BC 00   ..Na..

883   A1BC jsr     SLITERAL 614E BC     <= DLITERAL d. would be better than SLITERAL u. .
 ok

: bar ." hello" 12345678. ;  ok
see bar 
...
size (decimal): 25 

0896  4C 9E 08 68 65 6C 6C 6F  20 BC A1 99 08 05 00 20  L..hello  ...... 
08A6  7F 96 20 BC A1 4E 61 BC  00  . ..Na. .

896    89E jmp          <= could show 'hello' here ?
89E   A1BC jsr     SLITERAL 899 5 
8A5   967F jsr     type
8A8   A1BC jsr     SLITERAL 614E BC 

[patricksurry]

this is the first part of splitting #78

[SamCoVT]

I went back and forth over whether or not to show the string data. I ultimately decided not to, because the DUMP at the top already shows it (when using SEE) and you can take the address and length and TYPE it yourself if you want to know. If you think it's useful to print it, you're welcome to add that and it's easy to limit the length if the string is too long.

Do let me know when you have things at a point where you think a merge makes sense. Also, you don't need to worry about fixing up results.txt - in fact, I'll recommend that you run the tests, but not include results.txt in your PRs, as they will likely break when I merge other PRs.

[patricksurry]

i'm happy to merge this now and make a separate ticket for improving the disassembly of the non-native double. it should be relatively rare occurrence with default nc-limit anyway.

then i'll untangle the rest of #78 for you to look at.