which way is faster?
in [ASM]
|
Prev: A little ASM 6809 program
Next: what is rsrc.rc?
From: //o//annabee on 15 Jan 2008 15:03 P� Tue, 15 Jan 2008 21:03:09 +0100, skrev //\\o//\\annabee <w(a)www.akow>: > P� Tue, 15 Jan 2008 21:02:12 +0100, skrev //\\o//\\annabee <w(a)www.akow>: > >> P� Tue, 15 Jan 2008 20:37:26 +0100, skrev Robert Redelmeier >> <redelm(a)ev1.net.invalid>: >> >>> Wolfgang Kern <nowhere(a)never.at> wrote in part: >>>>>>>> PUSH ecx >>>>>>>> L3:MOV eax,edi ;1 ;keep the line start >>>>>>>> REP MOVSD ;15+ecx*4/3 = 357 >>>>>>>> ADD eax,edx ;1 ;add scan line size >>>>>>>> DEC ebx ;1 >>>>>>>> MOV ecx,[esp] ;3 >>>>>>>> MOV edi,eax ;1 >>>>>>>> JNZ L3< ;1 ;total (357+8)*256 = 93440 >>>>>>>> POP ecx >>>> >>>> >>>> So why RDTSC reported ~2'000'000 instead of ~250'000, this is >>>> about eight times more ? >>>> The answer might be that the BUS-speed is limited to 66 MHz >>>> while the CPU runs on 500MHZ... and 500/66 = 7.57 = near 8. >>> >>> Perhaps, but if ESI is pointing at VRAM, >>> you are asking REP MOVSD to _read_ it. >> >> No, its pointing at "Kesys bitmap" Must assume thats ram. > > Woops. Could it be a bitmap stored onship? no. > >> >> " >>>> eax= 0 colour mask >>>> esi= source ;btw: KESYS.bitmaps aren't stored upside down! >>>> AND [vflag],0f0 ;clear all options >> " >> >> >>> Reading VRAM is _KNOWN_ to be extremely slow. Writing >>> VRAM is bad enough, but reading may wait for retrace. >> >>> >>> -- Robert >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >
From: //o//annabee on 15 Jan 2008 15:08 P� Tue, 15 Jan 2008 21:03:53 +0100, skrev //\\o//\\annabee <w(a)www.akow>: > P� Tue, 15 Jan 2008 21:03:09 +0100, skrev //\\o//\\annabee <w(a)www.akow>: > >> P� Tue, 15 Jan 2008 21:02:12 +0100, skrev //\\o//\\annabee <w(a)www.akow>: >> >>> P� Tue, 15 Jan 2008 20:37:26 +0100, skrev Robert Redelmeier >>> <redelm(a)ev1.net.invalid>: >>> >>>> Wolfgang Kern <nowhere(a)never.at> wrote in part: >>>>>>>>> PUSH ecx >>>>>>>>> L3:MOV eax,edi ;1 ;keep the line start >>>>>>>>> REP MOVSD ;15+ecx*4/3 = 357 >>>>>>>>> ADD eax,edx ;1 ;add scan line size >>>>>>>>> DEC ebx ;1 >>>>>>>>> MOV ecx,[esp] ;3 >>>>>>>>> MOV edi,eax ;1 >>>>>>>>> JNZ L3< ;1 ;total (357+8)*256 = 93440 >>>>>>>>> POP ecx >>>>> >>>>> >>>>> So why RDTSC reported ~2'000'000 instead of ~250'000, this is >>>>> about eight times more ? >>>>> The answer might be that the BUS-speed is limited to 66 MHz >>>>> while the CPU runs on 500MHZ... and 500/66 = 7.57 = near 8. >>>> >>>> Perhaps, but if ESI is pointing at VRAM, >>>> you are asking REP MOVSD to _read_ it. >>> >>> No, its pointing at "Kesys bitmap" Must assume thats ram. >> >> Woops. Could it be a bitmap stored onship? > > no. Can you please shut up now? > >> >>> >>> " >>>>> eax= 0 colour mask >>>>> esi= source ;btw: KESYS.bitmaps aren't stored upside down! >>>>> AND [vflag],0f0 ;clear all options >>> " >>> >>> >>>> Reading VRAM is _KNOWN_ to be extremely slow. Writing >>>> VRAM is bad enough, but reading may wait for retrace. >>> >>>> >>>> -- Robert >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >> >
From: //o//annabee on 15 Jan 2008 15:09 P� Tue, 15 Jan 2008 21:08:13 +0100, skrev //\\o//\\annabee <w(a)www.akow>: > P� Tue, 15 Jan 2008 21:03:53 +0100, skrev //\\o//\\annabee <w(a)www.akow>: > >> P� Tue, 15 Jan 2008 21:03:09 +0100, skrev //\\o//\\annabee <w(a)www.akow>: >> >>> P� Tue, 15 Jan 2008 21:02:12 +0100, skrev //\\o//\\annabee >>> <w(a)www.akow>: >>> >>>> P� Tue, 15 Jan 2008 20:37:26 +0100, skrev Robert Redelmeier >>>> <redelm(a)ev1.net.invalid>: >>>> >>>>> Wolfgang Kern <nowhere(a)never.at> wrote in part: >>>>>>>>>> PUSH ecx >>>>>>>>>> L3:MOV eax,edi ;1 ;keep the line start >>>>>>>>>> REP MOVSD ;15+ecx*4/3 = 357 >>>>>>>>>> ADD eax,edx ;1 ;add scan line size >>>>>>>>>> DEC ebx ;1 >>>>>>>>>> MOV ecx,[esp] ;3 >>>>>>>>>> MOV edi,eax ;1 >>>>>>>>>> JNZ L3< ;1 ;total (357+8)*256 = 93440 >>>>>>>>>> POP ecx >>>>>> >>>>>> >>>>>> So why RDTSC reported ~2'000'000 instead of ~250'000, this is >>>>>> about eight times more ? >>>>>> The answer might be that the BUS-speed is limited to 66 MHz >>>>>> while the CPU runs on 500MHZ... and 500/66 = 7.57 = near 8. >>>>> >>>>> Perhaps, but if ESI is pointing at VRAM, >>>>> you are asking REP MOVSD to _read_ it. >>>> >>>> No, its pointing at "Kesys bitmap" Must assume thats ram. >>> >>> Woops. Could it be a bitmap stored onship? >> >> no. > > Can you please shut up now? ahh, fck you, duuushbag! > >> >>> >>>> >>>> " >>>>>> eax= 0 colour mask >>>>>> esi= source ;btw: KESYS.bitmaps aren't stored upside down! >>>>>> AND [vflag],0f0 ;clear all options >>>> " >>>> >>>> >>>>> Reading VRAM is _KNOWN_ to be extremely slow. Writing >>>>> VRAM is bad enough, but reading may wait for retrace. >>>> >>>>> >>>>> -- Robert >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >> >
From: Dirk Wolfgang Glomp on 16 Jan 2008 02:37 Am Tue, 15 Jan 2008 16:07:47 +0100 schrieb Wolfgang Kern: > you'll need to scan the VESA info and find/set a linear mode, ... push ds pop es mov di, OFFSET VINF ; get vesa-info(buffer to store vesa info) mov ax, 4F00h ; es:di 256 byte int 10h cmp ax, 4Fh jnz ERROR cmp BYTE PTR[di+5], 2 ; major version number of vesa <2? jb ERROR lfs si, [di+0Eh] ; copy all vesa modi(pointer of modelist) mov bx, OFFSET MODI ; buffer to store vesa modi P1: mov ax, fs:[si] ; get the mode number add si, 2 mov [bx], ax ; store the mode number add bx, 2 cmp ax, 0FFFFh ; end of modelist? jnz P1 mov si, OFFSET MODI ; scan for specific mode(with 32bit) P2: mov cx, [si] ; get mode add si, +2 cmp cx, 0FFFFh ; end of modelist? jz ERROR mov ax, 4F01h ; get mode-Info add cx, 4000h ; mode + linear acess mov bp, cx ; store mode number int 10h ; es:di 256 byte cmp ax, 4Fh jnz ERROR cmp WORD PTR[di+12h], MaxX jnz P2 cmp WORD PTR[di+14h], MaxY jnz P2 cmp BYTE PTR[di+19h], 20h ; 32 Bit per pixel? jnz P2 and BYTE PTR[di], 80h ; linear access enable? jz ERROR cmp DWORD PTR[di+28h], 0 ; linear offset exist? jz ERROR ... ------------------------------------- ATI 9800 PRO VESA Modi(128MB) ------------------------------------- 4 8 15 16 24 32 Matrix ------------------------------------- 109 132 x 25 10A 132 x 43 130 132 x 44 182 10D 10E 10F 120 320 x 200 192 193 194 195 196 320 x 240 1A2 1A3 1A4 1A5 1A6 400 x 300 1B2 1B3 1B4 1B5 1B6 512 x 384 1C2 1C3 1C4 1C5 1C6 640 x 350 100 183 184 185 186 640 x 400 101 110 111 112 121 640 x 480 102 103 113 114 115 122 800 x 600 104 105 106 107 108 123 1024 x 768 107 119 11A 11B 124 1280 x 1024 ------------------------------------- NVIDIA GF 4 Ti4200 VESA Modi(64MB) ------------------------------------- 4 8 15 16 24 32 Matrix ------------------------------------- 108 80 x 60 109 132 x 25 10A 132 x 43 10B 132 x 50 10C 132 x 60 130 10E 10F 320 x 200 134 135 136 320 x 240 131 132 133 320 x 400 100 13D 13E 640 x 400 101 111 112 640 x 480 102 103 114 115 800 x 600 104 105 117 118 1024 x 768 106 107 11A 1280 x 1024 147 148 1400 x 1050 145 146 1600 x 1200 ------------------------------------- Dirk
From: Wolfgang Kern on 16 Jan 2008 06:19
Robert Redelmeier wrote: .... >> So why RDTSC reported ~2'000'000 instead of ~250'000, this is >> about eight times more ? >> The answer might be that the BUS-speed is limited to 66 MHz >> while the CPU runs on 500MHZ... and 500/66 = 7.57 = near 8. > Perhaps, but if ESI is pointing at VRAM, > you are asking REP MOVSD to _read_ it. Right, worst case are RD-modify-WR on actual screen pages, but I have ESI point to a nonVRAM source in this test. Reads from not current visible VRAM shouldn't be too slow. > Reading VRAM is _KNOWN_ to be extremely slow. Writing > VRAM is bad enough, but reading may wait for retrace. > Proper video drivers issue scrolling commands to the > GPU which crunches everything in an optimized manner. > And image loads from DRAM are done by the GPU busmastering. > Again, optimized with other graphics chores like rendering. > Unfortuneately, I don't think the docs are easily available. Yes, and that's why this comparision limps quite a lot. If we strip off all vendor specific support in windoze then this test can't be done at all (windoze default is VGA 1024*768,4 iw: "four"!). Perhaps one day we get the required info from the vendors ... __ wolfgang |