Amiga Coldfire project dead?

[Trev]

Why not build hardware-based dynamic recompilation (or translation) into the execution pipeline, i.e. an MC68000 compatible ISA that translates only the necessary bits to the ColdFire ISA (the "microcode," so to speak). Could such a solution be faster than a complete recreation of the MC68000 ISA in an FPGA? Or could a solution that translates from one ISA to another, e.g. MC68000 to ARM, be just as fast or faster?

[Piru]

Why not build hardware-based dynamic recompilation (or translation) into the execution pipeline, i.e. an MC68000 compatible ISA that translates only the necessary bits to the ColdFire ISA (the "microcode," so to speak).

Sound simple enough! Let us know when you're done.

[Louis Dias]

Why not build hardware-based dynamic recompilation (or translation) into the execution pipeline, i.e. an MC68000 compatible ISA that translates only the necessary bits to the ColdFire ISA (the "microcode," so to speak). Could such a solution be faster than a complete recreation of the MC68000 ISA in an FPGA? Or could a solution that translates from one ISA to another, e.g. MC68000 to ARM, be just as fast or faster?

FPGA-based solutions seems to be the best if one insists on 68K compatibility., look at the NATAMI/Minimig/ActionReplay boards.

See the long thread regarding Minimig-AGA core performance relative to a classic Amiga.

Natami in particular already has a cached memory interface that uses DDR2 in burst mode all the time.  This will allow Natami's blitter to be 100x faster than a classic.  Switching back away from cpu blitting will be necessary since accelerated Amigas' cpu could blit faster than the stock blitter chip.  This will not be the case with Natami.  The goal for Natami cpu is in the 100-150Mhz range however the memory interface will make it seem even faster.

[B00tDisk]

I don't even know if it's feasible but the best (?) classic Amiga accelerator card would be one based on an intel Atom or AMD Geode running an emulation of a 68k processor.  Not quite whole system emulation, just CPU emulation, in JIT mode.

But again, I don't know if that's even feasible.

[Trev]

@Piru

The sarcasm, it stings! It stings! ;-)

@lou_dias

FPGA-based solutions seems to be the best if one insists on 68K compatibility., look at the NATAMI/Minimig/ActionReplay boards.

That wasn't exactly what I had in mind. I was thinking more or smallish FPGA or some other piece of hardware that looks like a 680x0 but actually functions as a memory controller, instruction cache, translator, etc. It's probably easier to just wait for a faster FPGA solution and use an existing core.

[billt]

@Piru

The sarcasm, it stings! It stings! ;-)

@lou_dias



That wasn't exactly what I had in mind. I was thinking more or smallish FPGA or some other piece of hardware that looks like a 680x0 but actually functions as a memory controller, instruction cache, translator, etc. It's probably easier to just wait for a faster FPGA solution and use an existing core.

I'm not sure it's as simple as a chip in the middle to translate instructions on the fly, which sounds sortof like a hardware JIT recompiler. If you only convert an instruction at a time, how does it know if the host CPU is doing a "native" memory access or a "translated" memory access? Or would you not have such a thing as native code running, only translated code? If both are running, you need to know which is which, as native code can go direct to the given address, but translated code may need to go to translated addresses. I think some intelligence would be required to keep track of things. But others may know better.

An example of a software-only thing that only emulates 68K CPU, for ARM host, is Cyclone.
http://notaz.gp2x.de/cyclone.php

[Tension]

Erm, they have. AROS runs on more than just x86.

Sorry, you misunderstood me.

I was talking about converting AmigaOS to x86

[bloodline]

Sorry, you misunderstood me.

I was talking about converting AmigaOS to x86

Waste of time, just use AROS

[Tension]

Waste of time, just use AROS

How very droll.

[trekiej]

I like Bloodlines answer.
Is it possible to make an installer that will scan the application being installed and replace the code? Maybe it can scan it after installation and then replace it.

[Tension]

@ Bloodline & Trekiej

From yesterday:
http://www.amiga.org/forums/showpost.php?p=592136&postcount=11

[Iggy]

@ Bloodline & Trekiej

From yesterday:
http://www.amiga.org/forums/showpost.php?p=592136&postcount=11

Good God! Are we back to Octamed again? Nicholas claims it run on a Pegasos under Amiga OS 4.1.
So, at least for your use, a PPC based system makes sense.

[XDelusion]

I still long for the day when OctaMED S.S. works on my MorphOS machine.

[Tension]

good god! Are we back to octamed again? Nicholas claims it run on a pegasos under amiga os 4.1.
So, at least for your use, a ppc based system makes sense.

58 goto 52

[Iggy]

58 goto 52

Amiga.org the new infinite loop.

[Amiga_Nut]

Well, you could as well just ask them how they're going to handle any code that depends on:

• 68020 multiply/divide instructions behaving like they do on 68k
• MULU and MULS setting the overflow bit
• ASL and ASR setting the overflow bit
• MOVE.B ,-(A7) and MOVE.B (A7)+, changing ea by 2

As far as Atari TOS goes you only deal with pure 68000 and nothing ese. Even 68010s will crash GEM/TOS btw.