ZN wrote: >>exg: 474 rol: 168 ror: 367 roxl: 25 roxr: 45 > It would be interesting to see where the EXG, ROL, ROR, ROXL, ROXL > instructions occur. I would bet quite a few in the graphics driver...
Some values from the GD2 driver: exg: 180, rol: 34, ror: 189, roxl: 0, roxr: 1 > These are much more difficult to sort out - the big question is, wether the > actual operation must be .B or .L, in other words, the upper bits of the > register need to remain unchanged. The remainder of the register is not the only problem, though the over 2000 "swap" instructions indicate that the upper bits often are used. You also get a different flag behaviour. All in all much of the code can be pretty tricky and if you get only one change wrong you will regret it, because you'll be searching your ass off for the resulting bug. > And, of course, it is one thing if an emulated instruction EXECUTES > seldomly (as opposed to appears in the source code) or is executed > often, and/or nesteed in loop(s). Rewriting the latter code to be CF > compliant is well worth investing into, the rest can always be left > to emulation. Right. > For the cases where source is available, one can opt for automated > cross-assembly, using for instance MicroAPLs portASM68k. This is a tool > that ypu can download for free after you fill in a web registration form at > freescale.com. It is worth noting that MicroAPL offers other portASM > products, and indeed CPU emulators (called MIMIC) as well as > cross-compilers that can take 68k asm source and cross-compile them into C. > Freescale/Motorola is obviously very keen on getting CF to occupy a larger > share of the embedded market as these MicroAPL products are normally VERY > expensive. For instance, MIMIC that emulates 68k on PowerPC chips costs >>$5500 as a developement system and over $1000 as a deployment licence. > Anyone attempting to write an emulator, or indeed, that has written or is > using an emulator, should look at these figures... Looks like I may have to raise the QPC price :-) > At some point, whoever is doing either the cross-assembly or the manual > changes might decide, on a case to case basis, not to bother with certain > code fragments, and assume there is an emulator present. That should be the starting point before doing any modification anyway, having it run with unchanged source with an emulator. Everything else is optional at first, so to say. > For the cases where the source is not available, emulation is the only > recourse, but no doubt cases will crop up where emulation fails. Work will > have to be done to find the cause and patch the offending code by hand. One > would expect that these will be relatively rare occurences, but it is also > plausible to expect these cases to be tough nuts to crack. Too true, I guess. > The first needs to be tried and evaluated. The second is a different case > and for it, I propose something like an address extended 68000 but with > limited FPU support. Yes. > I have just looked at V4e user's manual and it appears that the FPU > is in fact semi-compatible to the 68060 implementation, however it > only does double precision. IIRC this can be converted to the QL > format but not as easily as Extended precision that was implemented > on actual 68040, 60 and the 68881/2 coprocessors. Problem is that double precision actually has not enough range in its exponent to cater for all QL values. That's why I have to use extended in QPC, too. > Knowing what instructions are often emulated is a good start to > optimizing emulation performance. I don't doubt that MicroAPL have > done their homework, but I can't help wondering if SMSQ/E and apps > have their own peculiarities there. Well, frankly I cannot quite imagine that a tool can understand that code good enough to do sensible changes. If it can then it truly is a marvelous application. >>Actually I would consider applications that store data below their >>stack pointer as broken anyway. > So would I. About the only thing i can think of where this could be used is > to produce a 'fake' stack frame and then adjust values, adjust the stack > pointer and call something by doing a faux-RTS. Very dirty and completely > superfluous coding practise, anyway. Even for that case there is the RTD command. >>> All of this sems a like a whole lot of bother >>Hm, it IS worse than I imagined. > But do we have any choice? Hmmmm... how are your chip designing skills? :-) Marcel _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
