Last visit was: Wed Jan 27, 2021 10:13 am
It is currently Wed Jan 27, 2021 10:13 am

 [ 7 posts ] 
 Extending 8-bit architecture and maintaining compatibility 
Author Message

Joined: Mon Dec 28, 2015 11:37 am
Posts: 10
This is a topic probably not that relevant today but of more historical interest.

There isn't many, if any, 8-bit architectures that managed to extended to 16-bit while maintaining compatibility. Most extended architectures started over with a clean sheet. The 8086 maintained source code compatibility. Is binary compatibility so hard to accomplish when extending the hardware or were the starting points just too bad?

The 6502 managed to extend to 16-bit with status flags for data/register size and reusing old opcodes with different sized operands. 6502 differed from most other microprocessors in that it had plenty of free space in the opcode map for extensions. Is it a requirement to have a certain amount of free space left to be able to extend or are there other successful approaches?

I don't know much of newer 8-bit processor families. It should be easier now to plan when we know that architectural extensions will eventually happen. Is there any other microprocessor family that have 16-bit backwards compatible instruction sets?

Mon Mar 30, 2020 10:47 am

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1542
Interesting questions!

I don't think there's any need for spare opcodes, if there's a spare mode bit in the status register. The '816 didn't quite do this, but it could have done - the 6502 has one unused bit in the status register.

Or, if there are multiple encodings for some operation, such as a NOP, it's possible to be very nearly backward compatible by repurposing one or more of the NOPs with something useful - ARM did this, eventually.

However, just because something is mathematically possible with the instruction encoding, it doesn't mean it's simple or cheap to make the hardware. This is more important when transistor counts are strictly limited.

The 8080 to z80 expansion is a good case study, although it's not well-described as an 8 bit to 16 journey. It's quite an expansion of capabilities, and the z80 has lots of spare encodings as a result of using prefixes. If transistor counts were not limited the z80 could have done almost anything. See this discussion:
"Most of the additional Z-80 opcodes are prefixed by bytes CB, DD, ED and FD which the 8080 treats as aliases for other instructions."

But times change, and when more software is written in high level languages, even assembly-level source compatibility isn't an issue. So this question probably applies most strongly to the 70s and 80s era.

Except, when designing a new ISA such as RISC-V, it is possible and desirable to leave spare encodings and perhaps spare modes. It's quite a modular ISA: various options, and allowable extensions.

Mon Mar 30, 2020 11:03 am

Joined: Mon Oct 07, 2019 2:41 am
Posts: 202
I always thought the 8 bit CPU's needed to have 9 bits -- 8 bits data, 1 bit end of string/BCD number
Let's face it, bytes only have the space for one data size in the opcode and that is the problem. 16 bit cpu's also have the same problem, one data size 16 bit words. (the pdp 11 does not count here).
Having mode changing opcodes works only while still having a 64K address space. The 4004/8008/8080/8088 series of chips used up all the tricks in having a 8 bit opcode size. The IBM 360 gave us 8 bit bytes but instructions where half word sized rather than byte sized. Need a to access a byte, use a 'string' instruction. The PDP 11, is word sized as well. It is not 8 bits architecture going upwards, but rather 36 to 32 to 16 bits arcitecture.

Mon Mar 30, 2020 8:19 pm

Joined: Wed Apr 24, 2013 9:40 pm
Posts: 190
Location: Huntsville, AL
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. The prefix bytes set one or more flags that control the operand size, add indirection to the addressing mode, and override the registers. The flags clear automatically at the end of each instruction. In this manner, 16-bit operations, stack-relative addressing, etc. can be supported on an instruction boundary. I could do this because of the number of available / unused opcodes.

For another example, look at the intel mcs251, a backward compatible extension of the 8051 microcomputer.

Michael A.

Tue Mar 31, 2020 1:30 pm

Joined: Mon Dec 28, 2015 11:37 am
Posts: 10
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.

So, 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 would be a good place for me to start looking? :)

Thu Apr 02, 2020 2:33 pm

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1542
There are other costs as well as transistor budgets, which might be worth knowing about or bearing in mind:
- cost of specifying the interactions between old and new
- cost of designing the mechanisms
- cost of verifying the mechanisms
- cost of documenting it for the end-users
- cost of specifying, implementing, and testing the toolchain (assemblers, compilers)
- cost of educating the end-users (marketing, training)
- cost of supporting their questions

You can see this, with the 65816, which is still poorly documented by the manufacturer, is supported by only one C compiler, and where Bruce's explorations of all the corner cases is quite a massive read.

So, if simple is better, then combining old and new is taking a risk. I think that's why historically the backward-compatibility path is only successfully taken by companies with lots of money.

Of course, for a hobby effort, all sorts of different trade-offs apply! But it's worth bearing in mind, when coming up with a new CPU, that you'll need at least an assembler, and probably a monitor/loader.

Thu Apr 02, 2020 2:43 pm

Joined: Wed Apr 24, 2013 9:40 pm
Posts: 190
Location: Huntsville, AL
spiff wrote:
Is your extension documented anywhere? I guess would be a good place for me to start looking? :)

You can find most of the documentation that I've produced here. An emulator based on Mike Naberezny's py65 can be found here. An assembler and a Pascal compiler can also be found in my github repositories.

Michael A.

Fri Apr 03, 2020 4:13 am
 [ 7 posts ] 

Who is online

Users browsing this forum: No registered users and 0 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software