Ciao, Everything started due to my curiosity to understand why smsqe on latest HW platform (040 and 060) was so slow in PAN and SCROLL operation (both for high and Ql resolution). 1 - SMSQE with GD2 using standard QL resolution use MOVEP instruction. There are no more than 20 MOVEP references inside the sources that I replaced with move and shift instructions. The result was more than perfect obtaining , using speed test program (test909), value aligned with the other type of test (math) , graphics from 6.4 sec to .6 secs. 2 - SMSQE do not use MOVEP in High resolution driver, but the concept beyond should be the same . Maybe MULU and DIVU are the responsible of this. Conclusion : no conclusion !! I personally do not have a deep M68000 assembler capacity to try to remove efficiently suspicious instruction , but I think a specific flag to identify recent platform (060 and 040) should be introduced in assembler compiler . I know this was already discussed .... Fabrizio --- Laurence Reeves <[EMAIL PROTECTED]> wrote: > > Marcel Kilgus wrote: > > Fabrizio Diversi wrote: > > > >>I need some help to traslate Movep instruction, is > it > >>correct what i did in the following example ? > > > > > > Yes. > > I'll add that doing all those rotates is very > inefficient and of course > affects the status register, which maybe it > shouldn't (the MOVEP > instruction does't touch it at all). > > I shan't quote "better" code, as it would vary > dependant of what was > being attempted. E.g. knowing that the address > involved was always even > (or odd!), caring whether the data bus was accessed > in any specific > order or if extra bytes could be fetched, etc, etc. > > The sort of game that you'll find in the Minerva > ROM, where every byte > saved on non-critical code meant another feature > could be squeezed in, > might have gone something like: > > ... > bsr.s getpl > ... > > getpl > bsr.s getpw > swap d0 > getpw > bsr.s getpb > rol.w #8,d0 > getpb > move.b (a4)+,d0 > addq.l #1,a4 > rts > > ... wildly inefficient in terms of execution time, > etc, but saving quite > a few bytes, especially if bits of it get re-used. > > Note. In Fabrizio's original code, using: > move.b 0(a4),d1 > instead of: > move.b (a4),d1 > typically causes an assembler to generate exactly > what is asked: a four > byte instruction with a zero offset for a4 in the > second word. > > > > > > >>What is the equivalent of : > >> > >>movep.w d0,0(a5) ? > > > > > > move.b d0,(a5) > > lsr.l #8,d0 > > move.b d0,2(a5) > > > > Viewed from the hardware on the bus both codes are > not an exact > > replacement, but this doesn't matter nowadays. > > > Note that the above code destroys d0.l (and the > status register) and > that doing a ".l" instead of a ".w" takes longer. > > > Ciao Marcel > > > > > > > > > Ah well... I chip in my two cents once in a while. > Hi all! > > -- > Lau > http://www.bergbland.info > Get a domain from > http://oneandone.co.uk/xml/init?k_id=5165217 and > I'll > get the commission! >
__________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com
