What exactly is very very slow? 10%? 20%? 50%?
The instruction takes maybe 20-30 times the cpu cycles it would on m68k. Even if the coldfire is clocked higher, this still is very slow. Naturally it depends on the complexity of the instruction being emulated and the optimization level of the emulation.
Obviously it all depends on the rate of the emulated instruction being executed. I look at things from worst case scenario perspective (say, tight loop with emulated instructions inside). The chip maker takes some random code samples and runs them thru the emulation. This gives some average values, but IMO the worst case results are much more interesting. The worst case scenerio is the thing that'll really make the system suck, if anything will.
The 060 suffered over a 20% hit in performance from traps since it depended on it's superscaler architecture for it's speed. A trap was like killing the execution of 2 instructions instead of 1.
Well, just taking the unimplemented integer instruction exception is 19 cycles, and this only includes fetching the first exception handler instruction. The exception alone is 20X or 10X slowdown compared against most instructions. This is more serious than any scalarity lossage.
But I've mentioned all this 3 years ago already
And that makes you right how? If you were wrong then you won't be any more correct now.
The available coldfire CPUs back then didn't have as high clockrate as now, and they did lack more instructions than today. So it's easy to see the "correctness" of the document does change over time. Some facts do change over time, and they eventually affect the conclusion. (That at least when applying the results in any given Coldfire CPU. At some point the CPUs evolve a to a point they will be fast enough to invalidate the claims.) It doesn't make the whole document wrong, though. So where was I wrong back in 2003?
Anyway, I was referring to slowness of the emulation traps and how to speed the emulation up. What's wrong with those statements in particular?
You were totally off base on the post about unexpected behavior caused by multiple reads or writes to hardware that would be caused by the instruction traps.
Off the base how? The fact is that the custom hardware does get confused if there are multiple reads or writes. The emulation programmer needs to be careful to avoid such problems (agreed, you'd still need to be quite stupid to make mistakes like that, but I've seen worse. This is especially easy mistake to make with large caches of today and if you forget that custom hardware is noncacheable: "hey why read the value to a register, it's in L1 cache anyway...").
My argument is that every small difference in behaviour or timing will make the Dragon less compatible in average, and less appealing to users who like the "amiga feel". Every unsupported feature or emulation glitch will drop some unknown app or game. You can't say that 10% of the titles won't work, or that 50% won't work, but the rule of thumb is that the more the thing differs from the actual real thing, the less compatible it will be, and the more apps/games will not work.
IMO using coldfire isn't justified considering the amount of incompatibilities it adds. The classic amiga hardware is failing, and will not last forever. Faster CPU (x86) and full emulation (WinUAE) is much more sound way to go for classics: For the authentic "feel", just enable cycle exact emulation and go, for power desktop use just enable the faster possible settings with JIT.
