Come on Thomas what wrong here.
Is today "the offical day of misunderstanding people" ?
You probably use the term "ISA" in a non-standard way. For me, it is the user-observable instruction set, completely with the encoding and the desired outcome and side-effects of each instruction. The ISA does not define the caching, speed, branch-prediction, prefetch-logic and so on because this does not change the programming logic. Any work on these issues is highly appreciated and well-motivated, don't get me wrong. But please, keep your hands from the instruction set, i.e. anything that makes software incompatible - either forwards or backwards.
And next year install a "flash update" which adds a FPU.
And next year after install " flash update" which adds some SSE instructions.
This is perfect for the users.
And a nightmare for any software provider. Gunnar, we are not talking about the intel enterprise here were we have enough market share to force software companies into using another random extension. It's a very small scene, and as soon as instructions are added, you are also creating incompatibilities.
Thus, in specific, using some "unused encoding" from the existing MC68K instruction set is a big no-no. Instead, Motorola had a clear interface how to extend the programming model,and these are the co-processor instruction slots. Whatever extension there is, it somehow needs to go into a documented set that is available for specifically this particular purpose, and not somewhere else. There need to be a documented way to find such extensions, and register them in the Os. The 68060 PCR register was a good start for that. Just randomly throwing instructions into some unused spots is IMHO a very bad idea.
Who knows which instruction set Joe User has loaded today? Do I really need to test all the instructions for availability? Do I really need "another move with zero extension to get a job done faster"? Or which job gets faster by this instruction in particular?
I highly doubt that this is a useful exension given that the focus is on legacy software.
I probably need for *some* specific tasks *some* specific extensions. A multiply-add-capable eight-fold vector logic would be a nice addition for a JPEG DCT, for example. But please: Allocate a co-processor ID for that, and do not throw that into the slots of the FPU or we're creating a big mess of incompatible extensions.
Imagine you could have turned your 68000 per flash update into an 68020 and then into a 68060.
Wouldn't this have been wonderful?
For whom? For me as a software developer, this is a nightmare. Oh, your software does not run today? So which core did you flash now? No, this core does not work... use one with SSE, but the cache we do not need this big? Oh, that's then slowing down your favourite game? Well, bad luck, then I cannot support you....
It's very simple: The more you go towards hardware, the more stable the interfaces you provide have to be. Given that the Os cannot move much carrying all the legacy cruft around, how much do you think can the CPU change? For me this sounds like "almost not at all".
So once again: Extensions - yes. But please, not in the general integer logic by mis-using "spare slots" for neat instruction encodings. No program gets seriously faster by "move.b d0,d(PC)" or "move byte zero-extended into d0". That's just polluting the instruction space and fragmenting the CPU landscape. SSE, yes, vector units, yes, ... but please each in its coprocessor space were it belongs, with a flag I can easily test.
