Re: [ql-users] NEC Birmingham - 'Come on down'
- Original Message - From: "Alex Wells" <[EMAIL PROTECTED]> To: "dndsystems1" <[EMAIL PROTECTED]> Sent: Wednesday, September 18, 2002 10:14 PM Subject: Re: [ql-users] NEC Birmingham - 'Come on down' > . > > > > Hi Alex, we don't have a Q40 to test it on (Derek has taken some bits > > off his old Q40 so we cannot run that at the moment) but we can > > experiment on yours at the NEC if you like :-) > > > > Dennis - D&D Systems > > YIPPEE ! Yes please. > > Alex. > Derek should be firmly installed in the N.E.C. now, I will join him tomorrow for the 2 day bash. If the 'big show' at the NEC is well attended then the general plan is to have 2 per year starting next year. Anyone going to Byfleet on Sunday should think about 'dropping in' to see us on Saturday if you are passing. We will be exhibiting the latest Q60 which is a complete system and has an attractive price attached to it. All those that have contacted us will have the first machines and from there on it will be first come first served. We will be trying out some new software which might be interesting to some of you. Just look for the 'Men in Black' (and women). It's Q60 party time! See you there, Dennis - D&D Systems
Re: [ql-users] Movep
On Fri, 20 Sep 2002 at 15:09:37, Tony Firshman wrote: (ref: <[EMAIL PROTECTED]>) > >On Fri, 20 Sep 2002 at 11:23:29, Laurence Reeves wrote: >(ref: <[EMAIL PROTECTED]>) > > >>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, >One feature per byte is a mite better than even _you_ could manage (8-)# >FOR j=1 TO 3, rather than 'FOR j = 1 TO 3' and so on, but quite >automatically. Sorry I now remember your cunning. You actually typed: FOR j=1to 3 which impressed me. -- QBBS (QL fido BBS 2:252/67) +44(0)1442-828255 tony@.demon.co.uk http://www.firshman.demon.co.uk Voice: +44(0)1442-828254 Fax: +44(0)1442-828255 TF Services, 29 Longfield Road, TRING, Herts, HP23 4DG
Re: [ql-users] Movep
On Fri, 20 Sep 2002 at 11:23:29, Laurence Reeves wrote: (ref: <[EMAIL PROTECTED]>) >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, One feature per byte is a mite better than even _you_ could manage (8-)# I well remember your general attitude in saving bytes. eg use JMP not JSR when the called routine was the last action. You use this for instance when you call BP.INIT. ... and your comment that using MT.INF (for system variable base) was actually shorter than accessing the literal address - which allows for easy patching of dodgy code. I reckon you would win all competitions for compact code, but readability is a different matter. eg in superBasic you often had: 10 a% = b% I spent ages looking for the variable b%, until I realised it was a function (8-)# You hate superfluous bytes, and I have seen you in my own basic code almost unconsciously removing superfluous spaces - even putting 'endif' knowing it would resolve to 'END IF' automatically. FOR j=1 TO 3, rather than 'FOR j = 1 TO 3' and so on, but quite automatically. Mind you having seen your asm, I reckon you would win the documentation prize too (8-)# There was one whole page I remember where the only code was something like: version$ = "2.65"; but was actually a seamless part of the comment. You would also document long arguments with yourself in deciding the best course of action. >might have gone something like: > >Ah well... I chip in my two cents once in a while. Hi all! ... and nice to see you reading the list. I know (from our recent very voluminous recent emails) that you are, but I keep forgetting you still read the list. -- QBBS (QL fido BBS 2:252/67) +44(0)1442-828255 tony@.demon.co.uk http://www.firshman.demon.co.uk Voice: +44(0)1442-828254 Fax: +44(0)1442-828255 TF Services, 29 Longfield Road, TRING, Herts, HP23 4DG
Re: [ql-users] Movep
Fabrizio Diversi wrote: >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. > The answer - MOVEP is not implemented on the 68060, so it will be being emulated in software after an invalid instruction interrupt! No wonder it takes an age. A good point to look out for in any other code (I can't recall if Minerva uses movep). >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 > >
Re: [ql-users] Movep
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.bd0,(a5) > > lsr.l #8,d0 > > move.bd0,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
Re: [ql-users] Movep
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.bd0,(a5) > lsr.l #8,d0 > move.bd0,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!
