Thanks for replying.
Yes, I was mostly thinking of the late 70s and the first step towards extending micro processors beyond 8-bit. However, my mind was locked into thinking only at extending operand sizes, so I missed other types of extensions. Z80 is a very good example, and I also need to take a look at MCS251.
Moving from 8-bit to 16-bit the design budget went from 4-8000 transistors to 20000-60000. Spending a few 1000 more on decoding the old instruction set seems to me like a minor price to pay to bring existing code base with them on a upgrade path. From 16-bit the compatibility resumed growing to 32-bit and beyond. But for some reason not many architectures could make the step from 8-bit to 16-bit. Taking that step, maintaining compatibility did not seem that important for a moment in time.
Maybe I overestimate the usefulness of compatibility back then. For computers it was mainly Intel/Zilog and CP/M that dominated. The user base was small and the step to make in microprocessors performance was great.
Regardless of the historical role of compatible processor lines it could be useful even in modern era. I guess we have different types of compatibility.
- Unused opcodes. New operand sizes and instructions can use those.
- Prefixes. Reusing opcodes with other operand size or modified instructions.
- Register/operand size modifier flags. Setting status bits that modifies size.
- Setting a compatibility flag. Whenever the processor is not in this mode it can use whatever ISA it like.
Instead of prefixing single instructions, what if a prefix worked on a sequence of instructions until a new prefix is encountered? That prefix could of course be seen as setting a processor mode.
I did some time ago stumble upon the 65020, a 32-bit extension of the 6502 with an interesting take. Taking the approach of extending the 8-bit opcode of 6502 to permanent 16-bit instructions with a high byte specifying more registers, data size, and instructions. The memory organization gets a bit strange trying to maintain binary compatibility with existing code, fetching the low and high byte from different regions.
http://www.ucc.gu.uwa.edu.au/~john/65020.htmlSo, instead of setting register and operand size modes, what about a mode setting opcode size? But then I realized that is what ARM is doing in Thumb mode.
MichaelM wrote:
I extended the 65c02 in a manner that maintains backward compatibility on an instruction basis. Instead of using mode bits in the status register, I decided to use prefix bytes.
Is your extension documented anywhere? I guess 6502.org would be a good place for me to start looking?
