Peter Persson wrote:
Yes, we could do that if someone wants to add compatibility for ColdFire binaries on 680x0, but I don't think it is a good idea ;-)I don't think it's such a bad idea - but it depends on the code. It's not suitable for time critical stuff, obviously.
By adding compiler support for new CPUs, I want to provide the developers with the tools ready to use for producing several binaries of their software, fully optimized for the different CPUs. So I hope that people who will release ColdFire binaries will release also binaries for 68020+ and 68000, if it makes sense.
I've found that even "clean" apps calls the Line A to retrieve the variable list. It's probably unused though.
Yes, clean old apps calls the Line A, because it is was a clean and documented API. So an OS that claims to be TOS compatible must support it in some way (I still wonder how it will be done on ColdFire OS).
The point with using the TRAP approach is that it's easy to patch - just replace $A000 in the binary with the corresponding TRAP opcode.It's easy to implement in the OS too.
I didn't understand exactly what Didier did (I asked him yesterday for precisions). By patching an executable, it is possible to replace 1 Line A call by 1 trap, but there is not enough traps for all the Line A functions (if I remember well). Using automatic memory patching in the OS would be tricky, if not impossible, because the Line A opcodes bytes (ex: $A000) could appear somewhere in constant data, these ones should not be patched. And I don't know how to decide automatically if the bytes must be patched or not.
-- Vincent Rivière