On Jun 20, 8:00 pm, LouisB <[email protected]> wrote: > Fadden, thanks for taking interest. I've been racking my brain for a > few weeks now trying to come up with optimizations. Sofar nada. I > definitely have an Apple][ APK - how can I share?
I nosed around with "dexdump -d" for a bit. EmAppleII.readMemory() does a fast path for < 0xc000. It gets the "byte[] mem" field, grabs a byte, and ANDs it with 0xff to drop the sign extension. Not much less you can do there. Same story for _eaimm_. The only way you can speed this up would be to avoid the field lookups by passing values around in arguments. For example, executeInstruction() could grab "mem" at the top and pass it explicitly into readMemory() and the helpers like _eaimm_. That would save one field lookup every time you touch memory. If "mem" needs to be looked up every time, because you're doing something tricky like extended 80-column support, that might not be an option. You could "manually inline" some of the readMemory calls, but that would be ugly and painful to maintain. You could keep PPC in a local in executeInstruction and import/export when the value changes, but again that's annoying. You can replace calls to Em6502._incppc_ with a simple "PPC++", avoiding the method call overhead on top of the field read/modify/write, but that breaks the 6502-vs-Apple2 abstraction. Another way you can be faster: change "PPC = (PPC + 1) & 0xffff" to "PPC++". In practice nobody executes code off the top of memory, so it's not worth masking the address on every instruction byte fetch. There is no execution-time overhead for a "try" block that catches IndexOutOfRange, so you can just catch the exception should something actually walk off the end of the array, and have a special handler that masks before loading. Ditto for data loads on e.g. indexed instructions that might walk off the top -- very little code would have reason to index off the top of memory.) How are you determining performance? letting the game run and measuring the animation speed? BTW, at some point you'll want to add support for a virtual keyboard. Not all devices have physical keyboards, which makes it tough to get things going. > p.s. i'm looking in traceview and a function (_eaimm_ - fetches an > immediate from mem[PC] and increments the PC) shows Incl% 58.2% self, > 22,3% read memory and 19.5 _inppc_ - What does the "Self 58.2%" > represent? There's nothing there except for the two function calls. That is pretty strange. Not sure why it's reporting that way. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
