Closed ZornsLemma closed 7 years ago
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.
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
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.
Thanks Dave, I've made that change and pushed it to the branch - let me know if I need to do anything else.
Seems sensible to me; I've committed this to the cffb branch if you want to merge it. Cheers.
I've updated the codegen.c file and added CFFB to the portable VM in master
Great, thanks Dave!
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...