Phoebus R. Dokos wrote: > Not all of course but select few (like MOVE16 for example)
Now you're already excluding the SGC. > and especially the math ones could be significantly be sped up (if > you even take into account the FPU part of 040 and 060 there is a > significant boost up to be had)... Well, nobody is stopping anybody from doing a new SMSQ/E math module for FP aware machines. >> Actually emulators would gain far more than the native hardware if >> your assumption is right and the instruction count could be >> significantly reduced. > That is possible but not necessarily; if the emulated instruction would > need more native instructions to be emulated for example.... Of course it would need more instructions, 68020+ took the CISC approach to a rather absurd extreme. But that doesn't matter. Most time is spend in decoding the instruction, not in emulating it. Therefore, the more work a single instruction does, the better the work/overhead relation gets. > Speed up on a well written and mature emulator core like QPC's for example > can be achieved by the extra processing power without the hassle of > potentially re-writing parts of the emulation core and maybe in the > process introducing some new bugs (which probably doesn't apply in your > situation given the known quality of your software :-) but still it is > possible) Thanks, but you wouldn't want to know how long it took to get the 68k core as free of bugs as it is now. ;-) A single emulated instruction can currently already have a few thousand different code paths. Now imagine a bug that happens only after a few millions of those have already been emulated (I had those). It's a nightmare. Marcel _______________________________________________ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm
