Welcome, Guest. Please login or register.

Author Topic: ColdFire V4 Amiga accelerator project from the m68k emulation perspective  (Read 4332 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline Karlos

  • Sockologist
  • Global Moderator
  • Hero Member
  • *****
  • Join Date: Nov 2002
  • Posts: 16879
  • Country: gb
  • Thanked: 5 times
    • Show all replies
Id have to agree with the basic notion that existing methods for executing the code would be simply too slow.

Trapping instructions would be a killer - real 68060 cards that shipped with poor 68060.library TRAP based emulation often turned in slower performance than 030s for some code (especially stuff making heavy use of 32-bit muls/divs).

As detailed in the report, patching the unimplemented opcodes with jsr instructions is an option also.

However, there are a lot of opcodes to patch (unlike for 040/060) so the indirection could cause a slowdown too (not as bad as TRAP though).

My guess would be the best way forward would be to do what everybody else does to run 68K code these days and create a JIT emulation.

The JIT for a coldfire cpu could be a bit less complex than for eg x86 and could still make direct use of most instructions giving a decent transcription ratio.

I'd imagine that in many cases the transcription would be little more than expanding the unimplemented 68K code inline and keeping track of PC relative references in the current block as the transcripted code lengthens in relation to the original...

That could be pretty swift :-)
int p; // A
 

Offline Karlos

  • Sockologist
  • Global Moderator
  • Hero Member
  • *****
  • Join Date: Nov 2002
  • Posts: 16879
  • Country: gb
  • Thanked: 5 times
    • Show all replies
Quote

jdiffend wrote:
FWIW, Motorola's own estimates of full cpu emulation based on millions of lines of existing code is much better than what is mentioned here.
BTW, the 4e core (which Motorola has been talking about with developers a lot) will help a little too.


Well, theyre targetting the embedded applications market with coldfire. Much of the development for that will use specially adapted compilers / assemblers etc. generating code for specific applications. So full compatibility with existing 680x0 stuff isn't seen as that much of an issue.
If it were, the (d8, An, Xn) addressing modes would definately not have been dropped, since a lot of code uses this, especially on 020+.

Running unmodified code designed for a full 680x0 computer system is not quite the same thing as Motorola intend for these devices and woud require a fair bit of work to emulate efficiently.
int p; // A