Adding coprocessors on the same silicon is one thing, but changing the instruction set is a little extreme. They license a core from ARM and changes to that core would be more costly then adding some custom silicon to the chip.
Let's take an open source software analogy. I got this wonderful code from a group that is really picky about patches but has a good plug-in architecture.
I can change the core code. When new software shows up, I have to try and re-patch the software to add back in my core changes. I might try to submit my changes to the group, but if they are not broadly useful, they won't get adopted.
I can add my stuff through the plug-in architecture. It is a known expansion path, cheaper, and has less of a chance of breakage due to it being the preferred, documented method. Sure, when new software shows up, I will probably need to make some changes, but it will be easier.
Comments
Adding coprocessors on the same silicon is one thing, but changing the instruction set is a little extreme. They license a core from ARM and changes to that core would be more costly then adding some custom silicon to the chip.
Let's take an open source software analogy. I got this wonderful code from a group that is really picky about patches but has a good plug-in architecture.
I can change the core code. When new software shows up, I have to try and re-patch the software to add back in my core changes. I might try to submit my changes to the group, but if they are not broadly useful, they won't get adopted.
I can add my stuff through the plug-in architecture. It is a known expansion path, cheaper, and has less of a chance of breakage due to it being the preferred, documented method. Sure, when new software shows up, I will probably need to make some changes, but it will be easier.