On 03/12/04 at 02:19 Marcel Kilgus wrote: > For the fun of it I did some greps over the whole sources on my first > WIN partition (mostly SMSQ/E and some stuff like QPAC2, EasyPtr etc) > to have some data: > >dbcc: 324 exg: 474 cmpm: 24 rol: 168 >ror: 367 roxl: 25 roxr: 45 >ori2ccr: 7 >eori2ccr: 1 andi2ccr: 5
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... >> Long-word forms only: Most arithmetic and logical instructions can act on Long words only.... > >add: 3417 adda: 222 addi: 36 addq: >1853 >addx: 225 asl: 48 asr: 80 cmpa: 12 >eor: 175 eori: 14 lsl: 803 lsr: 804 >neg: 314 negx: 1 not: 270 or: 847 >ori: 67 sub: 1685 subi: 43 subq: >2504 >subx: 4 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. 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. >Well, but basically I see two classes of instructions: the ones that >are seldom used and therefore emulation is fast enough and the ones >that are so often used that it is not manageable to exchange them... Actually, it's not as simple as that. There are 4 basic cases: Emulated/replaced * source_available/source_not_available. 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... Even though PortASM68k is free, it is quite well documented and it is probably well worth unleashing on selected parts of SMSQ/E source and then looking carefully at the output and log files. It is actually a rather clever program, however, someone deeply involved in the source could probably do a better and far more optimal modification by hand. The big question as always is the tradeoff between suboptimal code that takes a fairly short time to produce using an automated translator, or optimal code that takes a longer time to produce by hand. IMHO optimisations are sure to follow once an automated translation starts working - and some (possibly considerable) hand optimizing will take place. The crux of the matter is, does it actually take any longer to get the finished product (as opposed to working product) if optimizing by hand was done from the start for the most critical sections of code, without the automation ever being used? The real test of how well such translation performs would be passing the sources for SMSQ through it, assembling them, and running them on the same machine (the differences re USP/SSP and associated stack behaviour should be left alone, portASM provides for this), then comparing code size and performance. 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. 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. What it comes down to is this: 1) How good is PortASM at what it does? 2) How good is the emulation library and what instruction set should be emulated? 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. 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. 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. I have both portASM and the emulation library and documentatin, and can send them to interested parties. >> On ColdFire, it is never safe to write below the stack >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. >> All of this sems a like a whole lot of bother > >Hm, it IS worse than I imagined. But do we have any choice? N. _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
