@Matt Hey and Gunnar. Can you make the Coldfire compatible via a software library?
I don't think anyone involved with the Phoenix/Apollo project has considered a software library for 100% ColdFire compatibility up to ISA_C (excluding MAC, EMAC and FPU) but it could be done if there was a specific purpose and enough demand. The focus was to make CF as instruction level (not necessarily binary) compatible as practical. Assembler source code could be converted through the use of aliases and macros but some hand modification would likely be required. For example, MOV3Q is in A-line which is not good for 68k compatibility but an ISA alias could convert it to assemble as a new sign extended longword addressing mode. It would be helpful for CF compatibility if the stack (A7) alignment could be configured to word or longword alignment but I don't know how difficult this would be to do in hardware. The DIVSL/DIVUL encoding conflict and different CC flags for multiplication means that it is not possible to have 100% binary compatibility for CF in an enhanced 68k CPU.
To which Coldfire you want to be compatible?
Which model - which Coldfire ISA?
For me to understand - Can you explain why you want this?
There are libraries of ColdFire code and compilers which are more modern than what the 68k has. There is a ColdFire embedded market which is larger than the total 68k market (although probably shrinking) and needs a replacement which could be Phoenix if it was compatible enough.
It seems like a bait and switch. Yeah you can have 400mhz 68060 speed, except you need to port your code to it and the new code won't run on a real 68060.
For compiled code to take advantage, the compiler support and backend code would need to be updated. Adding FPU registers can be done in an orthogonal way (as I proposed anyway) which would make this job much easier. The main changes would be interleaving the FPU instructions using the additional registers and coming up with an ABI which passes FPU registers to functions instead of using the stack. I created the vbcc vclib m060.lib math library, fixed a lot of bugs and added many new c99 math functions in a few months. There could be issues with precision in the vclib code (based on the 68060FPSP) if Gunnar reduces the FPU to 64 bits. Extended precision allows to avoid tricks which are needed to maintain maximum precision with 64 bits only. Personally, I would prefer to stay with extended precision for compatibility but double precision is considerably faster in an FPGA.
However, can anyone explain me the use case for "move.l dx,d(PC)", or the use case for "move zero extended to register"? Sure, that's probably all neat, but the number of applications where such an instruction is useful to increase the speed by an amount that makes an observable difference is near zero. Leave alone without new compilers or assemblers around. Yes, I can imagine that for special applications like decoding a hand-tuned inner decoder logic could be tremendously useful and worth the manual work. But seriously, is anyone saying "Ok, I'll now rewrite my application because I have now a move to dx with zero-extend instruction available, and THAT was exactly what I was missing?".
While I see limited use for PC relative writes, I think the encoding space used can not effectivly be used for other purposes and the protection provided by not allowing PC relative writes is a joke. I doubt compilers would bother with creating a new model like small data or small code but it should be possible to make tiny programs a little smaller and more efficient with PC relative writes opened. I would be willing to go along with whatever makes the 68k most acceptable.
The ColdFire MVS and MVZ instructions can be used very effectively by compilers and peephole optimizing assemblers (an important considerations of an ISA). The support is already available (ready to turn on) as most compilers share the same 68k and CF backend. I'm confident that Frank Wille could have support working in vasm already with a partial benefit in a matter of hours. Turning on the backend CF generation would be a little more work but requires more testing. Sure, it's not going to make a major difference but few integer ISA changes will (exceptions improve branch performance). The applications are obvious enough. Look at the code your layers.library produces and see how many places the MVS and MVZ instructions can be used. The intuition.library is another example where these instructions would be very useful. Of course, the gain is probably only going to be a few percent in performance and code density but it's easy as compilers can use it. Some code would barely use them at all though.
I'm surprised you never got into compilers. Your assumptions may be true most of the time but sometimes the 68020 addressing modes and ISA changes do make a big difference. For example, you say the 64 bit multiplication instructions are rare and they are for SAS/C but GCC has been using them since the '90s to convert division by a constant into a multiplication. Simple code like the following compiled for the 68020 with GCC will generate a 64 bit integer instruction.
scanf("%i",&d);
printf("d / 3 = %d\n", d/3);
The GCC optimization saves quite a few cycles. The 68060 ISA designers failed to recognize that GCC was already using this effectively. I'm working on a similar but improved magic number constant generator which I hope can be incorporated into vbcc. It's possible to use magic number constants for 16 bit integer division which GCC does not do. I may be a cycle counter because I know cycles add up but I still go after the big fish. I pay close attention to what compilers can do and where they fail. One thing I can't fix is where programmers fail. Another example of where the 68020 makes a huge difference we recently fixed in vbcc. The current vclib is compiled only for the 68000 like you think is good enough for your programs. Using ldiv() generated 4 divisions (lacking the 68020 32 bit division instrucitons and doing a division for the quotient and again for the remainder) and included a 256 byte table used for clz (lacking the 68020 BFFFO instruction). The next version of vbcc should have 68020 and maybe 68060 compiled versions of vclib but I fixed ldiv() for now with a single inline DIVSL.L in stdlib.h when compiling for the 68020+.
It is important to consider what the compiler developers think. They know what they need and can use. They should be part of the process of ISA development but the hardware developers (or should we say Gunnar) dictates what they will get. We can see that the ISA creation process has become secretive as can be seen by Gunnar refusing to answer questions in public (I showed how it is possible to mark an ISA with a disclaimer saying that it is for evaluation and subject to change). I tried to create an open ISA early for debate to try to avoid exactly these types of problems but most of the feedback I got was "there is no need yet". Even if my foresight is better than most people's hind sight, it wouldn't do me any good because nobody listens to me no matter how right I am. The truth doesn't seem to matter anymore.
