Nueron / NuOS (ColdFire based project)

[Karlos]

Looks cool :-D

This guy and Oli HD should get in touch!

[Karlos]

@ Coldfire experts...

If I am not mistaken, the coldfire processor misses some instructions / addressing modes that impact on 680x0 compatibility.

I understand that motorola have a code base for 'emulating' the missing functionaility that operates through a trapping mechanism, but I expect that heavy use of this could cripple performance.

What occured to me was the idea of using a JIT mechanism on a coldfire to emulate the 680x0. Before anybody suggests I am crazy, I literally mean to process the code and 'expand inline' anything that would need emulation on coldfire. For the most part, the emulation would not need to modify the original 680x0 code.

It transpires this idea isnt as stupid (or as new) as it might sound. HP already managed something similar with their PA-8000 Dynamo system which even manages to run PA-8000 code on the PA-8000 faster than running the same code natively (thanks to intelligent optimisation techniques).

I'm sure it would not be impossible to create a similar engine to allow 680x0 code to run on the coldfire without relying on trapping unimplemented code every time...

[Karlos]

@downix

Really? I was under the impression that a fair few things were missing, such as scaled indexed addressing modes, word addition to address registers and so on. My understanding was that the software from motorola used a mechanism similar to that used by the 68040FPSP to emulate missing functionality.

In any event, to the nay sayers I'd say a coldfire powered amiga would kick bottom so nerr :-P

[Karlos]

@Downix,

I'm not disagreeing with you - naturally the coldfire has its own supervisor architecture hence the OS would need extensive reworking.

The software doesn't know nor care of the addressing modes available, it cares about getting data to or from an address and the OS handles that.

Granted the physical address accessed is ultimately (thanks to MMU hardware) not necessarily the logical one generated by the application code, but I fail to see where the OS intervenes in for example

move.l (a0, d0.w*4), d1

or

add.w #2, a1

for instance. If, as I seem to recall (but may be wrong) these operations are not supported in the coldfire (along with others), some emulation mechanism must kick in to do the work.

Given I've seen plenty of d8(An, Xn*SCALE) modes in 020+ application code and add.w #, An in application code. If such operations have to be emulated by trapping or whatever, appication code using them will suffer.

Thats why I was thinking of some kind of JIT code translator that could for example convert

move.l (a0, d0.l*4), d1

into something like

movem d0/a0, -(a7)
lsl.l #2, d0
add.l d0, a0
move.l (a0), d1
movem (a7)+, d0/a0

on the fly and cache the cache the result (like any regular JIT). This has got to be way faster than invoking some kind of trap to emulate the missing address mode.

[Karlos]

@neuron

Unlike emulation of alien CPUs. such a 680x0->Coldfire JIT mechanism could be optimised in such a fashion as to leave big chunks of 680x0 code that is 100% coldfire compatible alone and avoid processing it.

However, when you consider HP's Dynamo it even begins to make sense to process it all. They get speed increases for code as a result of cacheing a linear sequence of instructions that represent a path through a complex set of conditions or a loop (its even more surprising when you consider dynamo is actually an interpreter 99% of the time and JIT converts hotspot areas only).

I've often wondered if such a JIT also makes sense on 68040/60 for running code that uses missing instructions emulated by the respective 680x0.library. Oxypatcher etc. is almost like this, but IIRC it patches the unimplemented instructions with a jump to code to emulate the instruction. Not as efficient as a genuine JIT, but much less work too. Its another alternative for running full 680x0 code on coldfire (maybe motorola's software does this ?).

[Karlos]

@bloodline

Your basic problem with an AROS 680x0 JIT emulation is portability. You will need codegenerators for every supported platform on which AROS runs.

[Karlos]

bloodline wrote:

Karlos wrote:
@bloodline

Your basic problem with an AROS 680x0 JIT emulation is portability. You will need codegenerators for every supported platform on which AROS runs.

Indeed, that's why UAE is a far superior option.

Well, not really, as I see it. UAE's JIT employs a layered design, the bottom layer of which is platform specific (x86 in this case).

Virtually all non x86 versions use interpretive emulation since (AFAIK), nobody has rewritten the JIT backend for other CPUs. Of course, I could be wrong about that.

A start for AROS would be to implement an interetive 680x0 emulation that at least stands a chance of being reasonably portable and worrying about JITs later.

[Karlos]

@bloodline

You can shy away from it and tout UAE all you like, but you can't deny that a 680x0 emulation (even if only interpretive) that allowed RTG friendly 680x0 apps to run under AROS would do a lot for the platform :-)