New PLASMA opcode - CFFB

[ZornsLemma]

Hi Dave,

I've created an experimental new opcode CFFB which allows small negative values to be represented as a two-byte instruction instead of using the three-byte CW. "CFFB $xx" is equivalent to "CW $FFxx".

By misusing the BIT instruction as described at http://6502.org/tutorials/6502opcodes.html#BIT, the new opcode only takes three bytes of extra code and two bytes in the dispatch table.

I don't know if you'd consider this a big enough win to be worth adding an extra opcode, but I thought I'd at least suggest it.

I should say that I've been testing this on my Acorn port and although I hope I've got the implementation on this branch correct, I haven't tested this Apple VM code.

Let me know if you have any questions, and take your time getting back to me of course - I know it's KansasFest right now!

Cheers.

Steve

PS I'm not wedded to the name CFFB if you like to take this but prefer a different name for the opcode...

[dschmenk]

Hi Steve- At this point in PLASMAs development I want to go through a process to ensure new opcodes are worthwhile. If you can show that there is a significant reduction in code size, or new functionality that isn't easily possible with existing opcodes, then I would refrain from adding them. I want to keep the VM from opcode bloat, so to speak. If an argument can be made, then I have no issue with it. Also, if an existing opcodes functionality could be tweaked to better support the language, no problem there, either - the reason I haven't gone to version 1.0 yet. Once 1.0 happens, then any VM changes would need to go in the 2.0 branch.

[ZornsLemma]

Hi Dave,

I understand. CFFB clearly doesn't enable any new functionality and it does offer a modest code size saving but it's not huge. I've done an ad-hoc statistical analysis of the code built from the PLASMA repository on this branch via:

find . -name \*.a -exec grep '!BYTE.*;' '{}' \;| sed -e 's/^.*;[ \t]//g' -e 's/[ \t].*$//g'|sort|uniq -c|sort -nr|cat -n and (after removing a couple of false positives) CFFB comes in with 63 uses, making it the 48th most used opcode out of 63.

Having said that, if I tweak that command line to examine the specific CFFB opcodes:

find . -name \*.a -exec grep '!BYTE.*;' '{}' \;| grep CFFB|sort|uniq -c

38 of them are 'CFFB $FF', i.e. a constant value of $FFFF=-1. This suggests that a single-byte opcode 'MINUS1' (or perhaps 'TRUE') might be worth considering instead - across this code base, CFFB would save 63 bytes in total (1 byte per instance as CW is 3 bytes and CFFB is 2 bytes) while a 'TRUE' opcode would save 2*38=76 bytes (2 bytes per instance).

Ultimately it's your decision, of course, and I won't be upset either way. I do intend to keep CFFB as a non-standard opcode in the Acorn port anyway - the Acorn OS entry points are all in the $FFxx range, so these constants are unusually common in Acorn code and CFFB pays for itself in the VM alone, even before considering any application program savings. I just thought I should see if it was of any interest upstream, it isn't a problem for me to maintain it solely in my tree.

Cheers.

Steve

[dschmenk]

Looks good. The only change I'm going to make is that there is one last unused opcode in the $00-$7E range: $5E. That gives the VM a nice round number of implemented opcodes.

[ZornsLemma]

Thanks Dave, I've made that change and pushed it to the branch - let me know if I need to do anything else.

[ZornsLemma]

Seems sensible to me; I've committed this to the cffb branch if you want to merge it. Cheers.

[dschmenk]

I've updated the codegen.c file and added CFFB to the portable VM in master

[ZornsLemma]

Great, thanks Dave!