Nueron / NuOS (ColdFire based project)

[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 ?).

[Doobrey]

MarkTime wrote:
I would rather poke a fork in my eye than buy a 200mhz coldfire.  By modern standards its slow, dog slow.

Why bother with the numbers game?
If it`s fast enough to run the software you want, then it`s fast enough.
 Remember this is isn`t gonna run WinBloat XP.

This is one sweet project, definatly reconsidering getting a VIA MiniITX now..

[that_punk_guy]

I love it when you guys talk technical ;-)

This looks really promising. I'm actually genuinely excited by this prospect. Who would've thought? :-D The form factor is really appealing, but I'm f**ked if I'm buying an XP tablet. I'm sure there's loads more people who feel the same way.

[bloodline]

Karlos wrote:
@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 ?).

You are probably more familier with JIT than I am, but I have been reading up about them. Yes I want that $10 bounty for AROS 68k emulator :lol:

They seem to work by scanning the code up to the first branch (conditional or otherwise), then translating the code it's just scaned into the native code and locating it as a block of code somewhere in the RAM.

In the case of a Coldfire->68K emu that would not need to change too much of the code.

Then it executes the translated block of code whch will jump to a point in the original code. This causes an exception which can be trapped, If the code jumps to a block of code that has been translated the pointer is updated to point to the translated code, if not,  the JIT then scans this code until the next branch and translates it to Native code (as done before). This code block is then located somewhere in ram.
This procedure is repeated during the execution of the program, after some time most of the code has been translated and executes at full speed, ie the blocks of code only ever get get trasnlated once.

If someone has any better explaination, I'd love to hear it!

[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.

[bloodline]

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.

[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.

[bloodline]

Karlos wrote:

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.

I should have made that clearer, I mean using UAE (not just the x86 JIT version, but), which already exists for all CPUs :-)

[FrenchShark]

Hello Stephen,

First of all, thanks a lot for your free tools. I use them with my MCF5282 board (I am develloping an exec.library for this little beast). I saw the pics of your prototype. It is really amazing ! The board looks very professional.

BTW, I noticed some little bugs on cfasm, I should send to you a bug report but, sometimes I am a little bit too lazy...

Keep up the good work, I am ready to pay $$$ for this beautiful HW.

Regards,

Fred

[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 :-)

[McTrinsic]

Back on topic?

Ok, here we go.

The first thing I though when reading about this was:


AWESOME! THIS KICKS ASS! ... (put randan exclamtion of extreme surprise and excitement here).

Unfortunately, a bit later my brain took over.

What I now think is: this is a brilliant piece of work,  but I fear it's to no avail. It yet ANOTHER bedside platform. If it supported AOS, it would be awesome - for me, for us.  As it is now, it is an interesting platform for embedded solutions.  Only problem: WinCE is already there. My company buys machines with WinCE as embedded OS on the it's terminals and user interfaces, and for partial control of segments of the machine (it's a project of a "4" and 6 zeroes behind it).

So while I admit is technically great, and exciting, and everything a geek likes to see and hear and would love to do, I can only imagine what addition your work to the Amiga market would have been. Imagine a "new classic" hardware, imagine the software-work gone into OS4 itself or into a project like Firebird or Java for Amiga or even OpenOffice for Amiga...

I am sorry that I am not giving you an enthusiastic answer like I wanted, but thats my point of view. Even worse, I fear that some programmers might actually be interested in your work and help you; which would mean a great loss for the Amiga scene.

I see it as another thing that might split the Amiga scene even more. Its really bad with OS4, MorphOS and AROS already...


McTrinsic

[bloodline]

Karlos wrote:
@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 :-)

Wile that is true, I think our "integrated UAE" (I'm getting sick of that term now) will be more popular. Since It will alloweven non system legal programs/games too run as well.