Enter the Dragon or enter the vapor?

[Karlos]

eslapion wrote:
I just spoke to an electrical enginer who's more into digital electronics than me.

He said the trapping method could be replaced by a huge (about 256MB) look up table that would essentially become the microcode for a conversion processor.

Essentially, you get the coldfire to run as a sort of interpreter that runs in loops into the 256MB and that tells it how to interpret the real 68k code.

This way, there is no flushing the pipeline.

;-) :-) :-D :lol: :roflmao:

Trust me, pipeline flushing would probably be *much* faster than this! Randomly accesed large lookup tables (anything larger than the cache) hammer any CPU, simply because memory access is generally one of the slowest things they do and such lookups tend defeat caches completely.

However, I doubt that such a lookup table would need to be quite that large. If you assume 680x0 code uses 16-bit instruction words most of the time, you'd need 65536 entries in your table. It would be larger than this due to extended opcodes, but 256MB is basically an immense overestimate.

Regardless, you are still talking varions memory read and computed jump instructions before you even get to emulating your opcode. This is not going to be quick at all.

I once wrote a small VM as an exercise that works in the manner you are suggesting. It has 256 possible instructions (an enumeration) and 16 general purpose registers (and some stack pointers) employing a load-store architecture. Instructions generally consist of byte pairs, one for the instruction and one for the effective address (mostly register to register, but depends on the instruction type).

A hand optimised assembly version of the interpreter uses a computed jump that is about as efficient as it can get for this (each instruction handler has the code required to calculate the next jump inlined onto the end of it, so you dont branch from a central loop out to a handler and back). The code table is about 16K, each handler starting at a cache aligned address.

It's an order of magnitude simpler than a real 68K and it gets about 2 MIPs on a 25MHz 040. With any luck you'll see this is not going to be a realistic option for a coldfire native 68K emulation.

[MskoDestny]

A dynarec/JIT doesn't really have to be all that slow. You don't have to deal with the mess of emulating a fundamentally different architecture, just expanding certain unimplemented instructions into multiple implemented ones. You don't have to deal with register mapping or simulating flag behavior (well except for those previously mentioned multiply instructions). Plus in theory, a sufficiently advanced dynarec can actually improve performance. HP's Dynamo is a dynarec that doesn't do any translation between architectures it just does processor specific optimizations and optimizations that can only be reasoned about at runtime.

[SHADES]

So, a thought....
How much more compatible is the v4e coldfire in instructions to say a 68020 or a 68000. Why do we need to emulate all instructions on a 68060 for?? most of the 68k apps are 020 or 68000 compatible versions. If it's easier to trap 020 code for exceptions than it is the multitude more on 060, why not forget about 060 completely.

I would rater a 200Mhz 020 based processor than a 100Mhz 060. Any newer programs designed from that day forth could be coded in native coldfire and hense get a speed increase. There is no real benifit to emulate an 060 or even 040. Winuae runs all the programs I use on 020 just as fast and I can always add in the 881 fpu if I want to use it that is and that's completely software emulation.

[Tripitaka]

SHADES wrote:
I would rather a 200Mhz 020 based processor than a 100Mhz 060.

I'd buy a 200Mhz 020 anyday.

SHADES wrote:
So, a thought....
How much more compatible is the v4e coldfire in instructions to say a 68020 or a 68000. Why do we need to emulate all instructions on a 68060 for?? most of the 68k apps are 020 or 68000 compatible versions. If it's easier to trap 020 code for exceptions than it is the multitude more on 060, why not forget about 060 completely.

I would rater a 200Mhz 020 based processor than a 100Mhz 060. Any newer programs designed from that day forth could be coded in native coldfire and hense get a speed increase. There is no real benifit to emulate an 060 or even 040. Winuae runs all the programs I use on 020 just as fast and I can always add in the 881 fpu if I want to use it that is and that's completely software emulation.

Actually, the thing that makes a 68040 run faster is the fact that it has fewer instructions built into it when compared to the 68020/68881 combination.

And the 68060 has even fewer instructions than the 68040.

In reality, what makes these processors more complex is the caching system and the pipelining architecture.

In the A1200, caching for the 68020 has no usefulness at all because the RAM is just as fast as the CPU. Not so when you run a 68060 at 60MHz or more.

Even if you can buy DDR SDRAM that runs at 266MHz or much faster nowawadays, we still have a serious problem of latency and caching is still necessary. In order to take advantage of the higher speed of this type of memory, you have to have burst access and only the 68030 and up have that.

So, even if you have a 68020 running at 200MHz, if its RAM responds at an equivalent speed of 20MHz because of lack of caching and burst access, what you'll end up with is like a 68020 running at 20MHz.

[Karlos]

MskoDestny wrote:
A dynarec/JIT doesn't really have to be all that slow. You don't have to deal with the mess of emulating a fundamentally different architecture, just expanding certain unimplemented instructions into multiple implemented ones. You don't have to deal with register mapping or simulating flag behavior (well except for those previously mentioned multiply instructions). Plus in theory, a sufficiently advanced dynarec can actually improve performance. HP's Dynamo is a dynarec that doesn't do any translation between architectures it just does processor specific optimizations and optimizations that can only be reasoned about at runtime.

Precisely. If you look up the other N threads about coldfire/68k compatibility you'll see I've given HP Dynamo as a working example of how a coldfire 68K-JIT could work.

[Oli_hd]

I've always hoped he'd open source everything if he didn't plan to take it any further *hint-hint*

Wouldnt help Im afraid, my problem was with the coldfire/68K bus interface with the V4 CF.
A V4e CF card may work, assuming you used the PCI bus of the CF as the interface between the CF and the miggy while keeping all address mapped correctly.
I have backtracked to the MCF5206 Coldfire which seems to have a bus that may suit the miggy more (There isnt a 5406 though, so if this did work I dunno where it would take me, except freescale have put up a "Make your own Coldfire" proggy which you build from the basic blocks and when the design is done it gets e-mailed to Freescale... what happens then I dunno, if enough people want the same thing maybe it gets made)
Im also doing a few other bits just to get more insite into miggy specifics. (AKA Im playing about with stuff)

[MskoDestny]

@Karlos:
Your posts are the only reason I know about HP's Dynamo. I just couldn't remember who had brought it up.

Oli_hd wrote:
Wouldnt help Im afraid, my problem was with the coldfire/68K bus interface with the V4 CF.

Out of curiousity, what in particular about the MCF5407 bus was the problem?

A V4e CF card may work, assuming you used the PCI bus of the CF as the interface between the CF and the miggy while keeping all address mapped correctly.

Too bad the 5407 is the only V4 or V4e Coldfire that isn't in the hobbyist unfriendly BGA package.

freescale have put up a "Make your own Coldfire" proggy which you build from the basic blocks and when the design is done it gets e-mailed to Freescale... what happens then I dunno, if enough people want the same thing maybe it gets made)

I would guess it's for high volume customers that are ordering in the kind of quantities that make a custom manufactured part practical. I could be wrong though.

[AJCopland]

Oli_hd wrote:

I've always hoped he'd open source everything if he didn't plan to take it any further *hint-hint*

Wouldnt help Im afraid, my problem was with the coldfire/68K bus interface with the V4 CF.
A V4e CF card may work, assuming you used the PCI bus of the CF as the interface between the CF and the miggy while keeping all address mapped correctly.

That seems to be a problem even with the 68060 etc accelerators too (though different I admit) would it require something like the GAL arrays or FPGA based bridges that they use to translate bus addressing and data signals?

Oli_hd wrote:

I have backtracked to the MCF5206 Coldfire which seems to have a bus that may suit the miggy more (There isnt a 5406 though, so if this did work I dunno where it would take me, except freescale have put up a "Make your own Coldfire" proggy which you build from the basic blocks and when the design is done it gets e-mailed to Freescale... what happens then I dunno, if enough people want the same thing maybe it gets made)
Im also doing a few other bits just to get more insite into miggy specifics. (AKA Im playing about with stuff)

Isn't the 5206 even less compatible with the 68k line than the 54XX series though? Or are you approaching it as a co-processor this time rather than a replacement host cpu?

Sorry for all the questions but it was reading about your CF project that prompted me to dig out my A1200 again and re-catch the Amiga bug... Dennis and the MiniMig just sealed the deal :-D

Andy

[Donar]

Oli_hd wrote:

AJCopland wrote:
I've always hoped he'd open source everything if he didn't plan to take it any further *hint-hint*

Wouldnt help Im afraid, my problem was with the coldfire/68K bus interface with the V4 CF.

Maybe someone could give you a hand if he sees more of your card/glue logic...

AJCopland wrote:
That seems to be a problem even with the 68060 etc accelerators too (though different I admit) would it require something like the GAL arrays or FPGA based bridges that they use to translate bus addressing and data signals?
...
Andy

Not that i know what i'm talking about, but maybe the information i heard helps...

For a Coldfire card to work it had to imitate dynamic bus sizing of the 030 (like it's done on the 040/060 cards) so i think your GAL/FPGA guess is right.

The information needed for this interface should be available from Motorola/Freescale but their implementation is not the fastest one. But hey it's a start.

[amigean]

so? What's happening? Any indication the dragon might still be released?  Is Elbox still trading?

(please don't reply if you "believe" or are "convinced" it won't be released - unless of course you have some evidence to that effect)

[Piru]

Donar on 2007/5/17 22:11:49

Lemmink wrote:
    ... but the Elbox coldfire will never go faster then any 68060 accelerator for the Amiga. The outcome of the presentation was that the card ran unmodified / optimised software at the speed of an 68040 at about 33 MHz. ..

The thing that i do not understand is: The Coldfire is (Mips wise) roughly 4 times faster than a 68060 @ 70 MHz it shares a good lot of instructions/adressing modes with the 68k (75%?). Why shouldn't it reach the performance of an 68060 or more?

I explained this 4 years ago in June 2003 already. See ColdFire V4 Amiga accelerator project from the m68k emulation perspective.

Anyhow, my prediction for the resulting speed wasn't far off. Dragon is actually slower than my predictions for the practical coldfire accelerators.

[derringer3]

Look, in elbox's webpage the Sharkppc cards were marketed that these cards will go into production when os4 finished. After 2006-dec-24, when hyperion announces that os4 finally finished, the ppc cards marketed, its available in Q1/2007. After 31th of March it is changed to Q2/2007. Now we're in the last day of q2/2007. So back to the dragon, i think the situation is the same. it will still the same in this year, if you asking me.

[Agafaster]

-D- wrote:
Another thing to keep in mind, "mips" isn't really an accurate way to determine processor speed. You'll get different results depending on what instruction is being tested, and an emulator throws this out of whack anyway. (F.e, I get 1500 MIPS in SysSpeed within WinUAE, and around 90 on my 68060.)

My personal opinion is that the Dragon is pure vapor.  No doubt, it would be very cool to see a fast 68k accelerator. I'm not so sure about seeing one faster than WinUAE on a modern PC though. ;-)

Allow me : MIPS = Meaningless Indicator of Processor Speed

[humppa]

@derringer3

Look, in elbox's webpage the Sharkppc cards were marketed that these cards will go into production when os4 finished.

When OS4 is finished? Even that is currently under debate. For the lawsuit, Hyperion wants to make it appear that it was finished in 2003/2004, Xmas 2006 they said that "It's done" and some months ago they announced that they are preparing the final ISO including packaging. So we have three dates that could be interpreted in such a way that "OS4 is done".
Elbox would still choose another date. Preferably one that lies far far in the future.  :-P

[amiga92570]

humppa wrote:
@derringer3

Look, in elbox's webpage the Sharkppc cards were marketed that these cards will go into production when os4 finished.

When OS4 is finished? Even that is currently under debate. For the lawsuit, Hyperion wants to make it appear that it was finished in 2003/2004, Xmas 2006 they said that "It's done" and some months ago they announced that they are preparing the final ISO including packaging. So we have three dates that could be interpreted in such a way that "OS4 is done".
Elbox would still choose another date. Preferably one that lies far far in the future.  :-P

Elbox has stated that production of shark will procede when OS4 is released. It has not been released and may not be for a while now with the ongoing court case. Why would anyone buy a shark PPC if there is not an OS to run it on?