9

The SPC700's instruction set is derived from the 6502's, but moves the instructions around and adds a few. But is it fully backwards compatible?

Assuming that the program fully separates data and code, such that opcodes are never used as data or operands, can a direct binary to binary transliteration be performed that leaves the SPC700 program operating identically to the 6502 version without changing any of the addresses of instructions?

|improve this question
  • Knowing that the program separates code & data is a great start, as that ought to rule out clever trick like using opcodes as constants (code as data); we would expect self-modifying code to also be ruled out by that (data as code). However, that is not quite the same as knowing which memory locations are code and which are data. I've seen binary-to-binary translation that accidentally interprets data as code, so it can be tricky. One problem is that data can be placed right next to code, and it is hard to know for sure in the most general case because of indexed branching. – Erik Eidt Apr 13 '18 at 19:37
9

The SPC700's instruction set is derived from the 6502's, but moves the instructions around and adds a few. But is it fully backwards compatible?

No.

At least not fully. The instruction set is mostly like a 65C02, but a few instructions (like BIT) are missing. Also, not all inner workings are the same (*1).

Assuming that the program fully separates data and code, such that opcodes are never used as data or operands, can a direct binary to binary transliteration be performed that leaves the SPC700 program operating identically to the 6502 version without changing any of the addresses of instructions?

With some luck. For example if there's none of the missing instructions used (*2). And no decimal arithmetics - as the SPC700 doesn't offer that (*3). Similar direct manipulations of flags may be problemetic, as structure and meanings differs (*4).

It might be a bit better when translating source code, but not much.

*1 - No decimal mode but Half Carry handling; moveable ZP, and more

*2 - Which could be detected by the translator

*3 - Harder to detect, but CLD/SED could throw a warning

*4 - Here it gets hard to manage, since a warning for every PLP would just flood the conversion listing.

|improve this answer
  • 1
    Though the SPC700 does not support a decimal mode (no CLD/SED equivalents) it does support BCD operations. Perform any add or subtract (that modifies the H half carry flag). Then DAA and DAS as appropriate after the operations. To convert this from 6502 code the context of D would need to be inferred on ADC and SBC and the DAA and DAS instructions added respectively, if D=1 was inferred. – Brian Jack Oct 5 '18 at 13:29
  • except the question wasn't abut what's possible with a SPC700, but if automatic (not magic) translation would be possible. Especially one on one translation without code rearangement - and deleting/inserting instruction won't work without. – Raffzahn Oct 5 '18 at 16:46
4

One can think of the SPC700 as a sort of hybrid 8-bit processor that tries to be a 6502, 65816 (16-bit) and Z80/80x86 (decrement-and-loop type instructions). As such it does not fit nicely to any of the individual processor architectures. It uses Z80 (and 80x86) style half-carry/DAA/DAS BCD semantics rather than a decimal mode (making it differ from 6502/65816) and does not have dedicated 16-bit registers (making it not a Z-80 either!).

It will be much better to hand convert 6502/65816 code into a SPC-700 assembly. Automagic conversion is going to rely on too much magic to have reliable conversion of arbitrary 6502 code to SPC-700. Just the decimal mode alone can be an issue if the 6502 code does not statically use CLD/SED around decimal mode logic but conditionally sets it or loads it from a computed-value flag pull (for example computing a value with logic that includes I/O reads into A that results in setting D-bit, PHA, PLP).

You will find a lot of code that is cumbersome on 6502/65816 variants (COUGH bit manipulation COUGH) is a lot easier in SPC-700 assembly. Need bit fields? No problem! The SPC-700 can set (SETB), clear (CLRB) and branch (BBC/BBS) on bits arbitrarily and even perform logic within the first 8K of RAM as a large individually addressed bit-field (AND1, OR1, EOR1, etc.)! The Z-80 doesn't even have that one. There are decrement-and-branch instructions too with likenings to Z80 (and 80x86)'s famous DJNZ and friends. You even have cool extras like a multiply and divide operation! There are also some 16-bit operations.

With all these extra architectural features it is simply sub-optimal to even attempt a 1-to-1 style conversion since the SPC-700 is going to nicely solve a lot of problems in far fewer instructions than the much larger 6502/65816/Z80 implementations, which will incur further overhead in an automated conversion. Oh and did I mention the zero (direct) page can also use page one on the SPC-700 (by setting the P bit the direct page instructions will access page 1 meaning you can get a small amount of additional direct page from the bottom of the stack page where the stack never reaches and use the direct page addressing modes within a subroutine to easily handle stacked parameters).

Long story short: the architectural differences are sufficient that any attempt at automated conversions will generate grossly inefficient SPC-700 assemblies. A good overview of SPC-700 capabilities is here: https://wiki.superfamicom.org/spc700-reference

|improve this answer

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.