[asembler] - koprocesor

**Glottis** · 09.01.2004, 17:15

cau, mam problem
zkosuim pocitat neco v koprocesoru a nejak to nechodi. napr zkusim tot a to to pocita spatne

Kód:

	finit
	fild	y
	fild	f320
	fmul
	fild	x
	fadd
	fistp	di_n
	fwait

a pritom by to melo byt podle me stejne jako tohle a to pocita jak ma jen bez kopru

Kód:

mov	ax,y
	mov	dx,y
	shl	ax,8
	shl	dx,6
	add	ax,dx
	add	ax,x
	add	ax,cx
	mov	di_n,ax

promene jsou takto definovane

Kód:

	X 	Dw 	0h
	Y 	dw 	0h
	DI_n	dw	0h
	F320	DW	320

nevite nekdo? neni u kopru nejaka bota? sakra to musi fungovat

potrebuju v nem siny a cosiny a kdyz nespocitam ani tole sme nahranej

**RayeR** · 14.01.2004, 11:54

Na chybu kopru bych to hnbed nehazel (pokud nemas nahodou stare P60

Bohuzel s koprem sem si nikdy nehral, tak neporadim, ale docela by me to i zajimalo. BTW jakej pouzivas ASM prekladac?

**Glottis** · 14.01.2004, 16:46

uz to mam vyresene, sice ne k plne dokonalosti ale mam.

pouzivam tasm. turbo assembler, ze

k te chybe. bylo to rukama, jak jinak. potreboval sme arctan jenze arctan jakozto FPATAN nedela jen ten arctan ale dela i deleni, takze to ma dva argemnty. ty to podeli a udela arctan.
ten ukazkovej kond jak sem zjistil nefunguje jen v tom jednom mem programu. nevim proc ale pocita to jen pro 32000 pixelu co tam davam souradnice, nechapu, ale to je fuk, to ponasibim v v normal cpu. asi nejak blbe nastavene ds nebo es nebo cokoliv :/ kazdopadne z toho vznikl nejpomalejsi rotozoomer

)))

**miho** · 14.01.2004, 19:34

Původně odeslal Glottis

ten ukazkovej kond jak sem zjistil nefunguje jen v tom jednom mem programu. nevim proc ale pocita to jen pro 32000 pixelu co tam davam souradnice, nechapu, ale to je fuk, to ponasibim v v normal cpu.

Ty dva uryvky kodu nejsou ekvivalentni. Koproc, pokud vim, ocekava cislo se znamenkem takze ti tam muze dojit po prekroceni 32767 k rozsireni vysledku na dvojite slovo (nesouvisi to s tim problemem, ze ti to funguje jen do 32000?). Oproti tomu v te prvni verzi pocitas jako bys mel neznamenkove cislo.

Chtel jsem se zeptat zda jsi delal testy rychlosti obou verzi? Mne prijde ten dvojity posuv a secteni jako rychlejsi nez to pasirovat pres koprocesor...

**RayeR** · 14.01.2004, 22:39

Glottis> Muzes prozradit na cem to robis, ze delas nakou grafiku pres FP funkce? Se mi zda, ze to asi pak nebude nejrychlejsi. Ja bych nejake ty vyssi operace sveril radeli GCC kompilatoru at dela co umi, pokud teda netrvas na pure ASM (asi kuli male velikosti).

Ja sem jednou zkousel delat takovy malicky programek v ASM, ktery nakresli Svejcarskou vlajku (byla to soutez Vyhen coding compo) a docela mi to stacilo. Muj kod mel asi 78 Bajtu, zatimco nejlepsi borci to meli asi na 40

Takze po te, co sem narazil na limity Pascalu sem se donutil do Cecka...

**Glottis** · 14.01.2004, 23:22

miho: to me nenapadlo ze by mi to mohlo pretect! na tom neco je. zkusim. kdyz to pujde zkusim posoudit rychlost ale ty posuvy budou asi rychlejsi. asi jak na jakem procesoru. p4 a tak maj kopr uz vymaklej, nejspis

apson co sem slysel

RayeR: aaaale delam semestralku na strojove orientovane jazyky. sem si vybral ze udelam rotozoomer tak ho pisu. musi to byt v asm. a nebo vkladany asm ale rotozoomer je tak jednoduchej ze to je lepsi napsat pure asm. jiank mas pravdu, neni to nejrychlejsi :/ naopak, je to nejpomaljis

)) na p3 mi to bezi tak nejak OK ale na p200 uz to je slideshow

tady se mzuete mrknout

http://michal.inorg.net/asm/sem/

**Glottis** · 14.01.2004, 23:36

mno tak je to opravdu tim intem ze ho bere zapornej a jen do 32000. takova blbost a ja na to zapomenu.

jinak subektivne se mi zda ze ty posuvy jsou rychlejsi, toci se to o kapaaanek rychleji ale porad nic moc. tam je pruser pocitani te rotace. je tam arctg a sin a cos a to fakt trva

lepsi by byli tabulky predpocitanych hodnot ale zase kolik by tech hodnot muselo byt, ze, prece jen dva pixeli od sebe to je minimalni zmena uhlu.
tady je kod jak to rotuju

je to osklive

ale kdyz nekoho napadne jak to zrychlit muzu to zkusit. kdyz nenapadne tak je to fuk. to by bylo uz jen pro me aby ztoho nebyl nejpomalejsi rotozoomer

Kód:

	PUSHA
        MOV     AX, @DATA	; NASTAVÍ SPRÁVNÝ DATA SEGMENT
        MOV     DS, AX
	FINIT
	FILD	F160		;POSUN NULOVEHO BODU
	FILD	XI1
	FSUB
	FIST    XI1
	FILD	F100
	FILD	YI1
	FSUB
	FIST    YI1
	FPATAN			;VYPOCET UHLU BODU ALFA = ATAN&#40;X/Y&#41;
	FLD	INCANGLE
	FADD
	FSTP	ALFA
	FILD	XI1		;VYPOCET VZDALENOSTI OD STREDU
	FILD	XI1		;SQRT&#40;XI1*XI1 + XI2*XI2&#41;
	FMUL
	FILD	YI1
	FILD	YI1
	FMUL
	FADD
	FSQRT
	FLD	SCALE		;PRIPADNE ZVETSENI ZMENSENI
	FLD	INCSCALE
	FADD
	FMUL
	FISTP	R
	FILD	F160		;POSUN NULOVEHO BODU ZPET
	FLD	ALFA		;VYPOCET NOVYCH SOURADNIC
	FSIN			;R*SIN ALFA
	FILD	R
	FMUL
	FSUB
	FISTP	X1
	FILD	F100
	FLD	ALFA
	FCOS			;R*COS ALFA
	FILD	R
	FMUL
	FSUB
	FISTP	Y1
	FWAIT
	MOV	AX,Y1		;320*Y+X
	MOV	DX,Y1
	SHL	AX,8
	SHL	DX,6
	ADD	AX,DX
	ADD	AX,X1
	MOV	DI_N,AX
	
	POPA

**miho** · 15.01.2004, 00:06

Mas to hezke. Pripomnelo mi to demicka na amize

Kreslis predpokladam primo zapisem do segmentu $a000?

Ty predpocitane fce to neni spatny napad. atan pocitas pro hodnoty x a y obe promenne v rozsahu velikosti obrazu. Cela tabulka se ti vejde do segmentu tak proc jeste vahas?

Usetris deleni a arkustangentu to je oproti vypoctu offsetu do tabulky (v podstate ty stejne posuny jako na konci) cela vecnost.
To stejne pro pocitani vzdalenosti (2xnasobeni, scitani a odmocnina).
Od ceho ty procesory ty dodatecne segmentove registry maji

Sinus takto nezoptimalizujes ale staci ti zase jen ctvrt periody, zbytek jsou symetrie. Cos je posunuty sinus.
Bez do toho, drzim ti palce

**Glottis** · 15.01.2004, 00:26

jeste je jedna rotace

brutalne rychla

a to tato

x=x´-y´*incalfa
y=y´+x´*incalfa

sice to neni az tak presne ale co

bohuzel se mi to nari nejak rozume rozjet. jen to tim otocim asi o 90stupnu ale je to rychlejsi asi 100 000

)) jako opravdu. stim predpocitanim to prad nevidim tak dobre. do segmentu se mi to asi nevejde. protoze obyc float ma 4byty, leda ulozit jen ctvrtinu a uhly jsou pak symetricke. uvidimjak bude cas a chut, odevzdavam uz v patek takze moc casu neni

jj kreslim primo kopii do a000h

**RayeR** · 15.01.2004, 10:57

Glottis>
Pekny, na nasem skolnim P4 to bezi asi 5fps

Za ty tabulky bych se docela premlouval, jednou sem dal takovy mikro demo, ktery melo bezet na XT (bez kopru), byla tam rotace 3D krychle, tak sem si udal tabulku sinu pro kazdej stupen a jak to panecku frcelo. Tady byde asi potreba vic hodnot, ale myslim ze by se to do 64k veslo.

Schvalne to zkusim napsat v C a uvidime kolikrat to bude rychlejsi. Akorat to nebude mit 1,5kB...

Ale nenech se odradit, ja ASMisty docela obdivuju, uz bych na to nemel nervy... (max tak na nakym mikropocitaci, ale to je zas vo necem jinym)

Jinak muj oblibenej prekladac na assembler je NASM.

**Glottis** · 15.01.2004, 12:13

nasm me nejak moc neuchvatil

btw na p4 5FPS

) to to na me p3 jede mnohem rychleji

**RayeR** · 15.01.2004, 14:03

Tady sou "jen" 1,5GHz P4, schvalne to zkusim este pustit doma. Jinak NASM se hodi kdyz delas naky programky do BIOSu, nebo MBR, kde chces primo flat binary a ne com/exe.

**Rainbow** · 15.01.2004, 14:11

Na Cyrixe mi to ide asi 4 FPS, takze ta P4ka by sa mala hanbit

**Glottis** · 15.01.2004, 14:38

je to podivne

na p100 mi to beha asi 2FPS (odhadem), na 486 33 tak neco pod 1FPS. na mojim uz se to toci hezky, ve skole na p4 1,5 neco mezi tou p100 a mojim hodn edobre to beha v jedne ucebne kde jsou nejake 500ky snad a bratrovy s p4 1,7 to beha hur nez me. zajimalo by me co to brzdi

jestli pamet grafiky take? mno je to zajimave

**miho** · 15.01.2004, 14:58

Tento programek bude na P4 urcite pomerne pomaly protoze pouziva FPU. P4 ma bohuzel jen jednu plnohodnotnou FPU jednotku (P III a Athlony maji dve) a spoleha na SIMD instrukce.

Kdysi jsem napsal clanecek na toto tema
http://www.zive.cz/h/Testcentrum/Ar....AI=2073&CHID=3
(psano pro prumerneho ctenare zive.cz, pocitejte s tim

)

**RayeR** · 15.01.2004, 15:32

Me se zda ze to nebude jen v CPU ale prave asi i dost v prenosu do VRAM. Tady je naka integrovana nvidia Vanta=sacka, a ma to zrejmne sdilenou pamet, tazke proto asi.

**Rainbow** · 15.01.2004, 15:35

P4ka je na normalne veci slaba...

**Glottis** · 15.01.2004, 16:51

peknej clanek
udivuje me ze by p4 nemela na posuvy barell shifter chmmm

a nenni nekde nejakej tutorialek jak na sse a mmx instrukce v asm?

**RayeR** · 16.01.2004, 01:11

Tak sem to poustel na mym stroji a bezi to jakstaks plynule, rozhodne lip jak na tom skolnim stroji. Ale videl bych to fak v ty gfx, ne v P4. Jinak clanek byl dobrej...

**Rainbow** · 16.01.2004, 12:25

IMHO to musi bezat nezavisle od grafiky bez problemov - to by malo aj na standardnej IBM VGA alebo Trident 9000 behat priblizne rovnako. Ked si spomeniem, co dokaze na 486ke s ISA grafikou robit demo Second Reality

**RayeR** · 17.01.2004, 04:49

Tak sem zkousel neco naprogramit v C, sice to rotuje rychle (rychles nez refresh monitoru), ale je to naky buggy, v tom obraze sou pri natocenim jinym nez 0,90,180,270... prazny pixely. Ja sem na to pouzil uz napsanou fci na kresleni obecny cary, takze rotuju jen pocatecni a koncovy body tech car, ktery se misto konstantni barvy krmi radkama z toho obrazku, jenze proste nak nesedou presne jedna vedle druhy. Asi uz bych se na to mel v tuhle hodinu vys.rat

**Glottis** · 17.01.2004, 11:13

nj kreslit carou to nejde. a kdyz po pixelech tak pro cilovej pixel pocitat zdrojeovej a ne naopak

**RayeR** · 18.01.2004, 04:19

Sakra, tak by me zajimalo, kde se bere ta chyba. Zistil sem, ze pri nepravym uhlu obcas dojde k tomu, ze se spocitana sourarnice, napr y posune o 1 driv nez by mela a na obrazovce pak zustane neprekresleny bod, tj prosvita pod nim pozadi. Dale pak zas dochazi k tomu, ze se nektery bod prekresli 2x, coz se v obraze okem nepozna, vysledkem je toto:

(zvetseny vyrez)
Rozlozeni tech neprekreslenych bodu zavisi na uhlu, rek bych ze nejvic jich je tak pri 60 stupnich. Tohle bylo tusim pro 20 stupnu.

Stejnej problem samozrejme mam i pokud se pokousim nakreslit jen natocenej obdelnik.

Dalsi vec, co by se mela resit je pixel aspect ratio, pri ty rotaci totiz obraz nevypadal pravouhly.

Zistil sem, ze kdyz ten obraz trochu zmensim (staci tak na 80%) tak se diky vicenasobnymu prekreslovani zaceli ty prazny mista, ale neni to rozhodne cisty reseni.

Jinak ted pouzivat tuhle transformaci, po bodech (floaty):

Kód:

  for &#40;j=0; j<img.yres; j++&#41;
    for &#40;i=0; i<img.xres; i++&#41;
      &#123;
      x=mag*&#40;i*cos&#40;angle&#41;-j*sin&#40;angle&#41;&#41;;
      y=mag*&#40;i*sin&#40;angle&#41;+j*cos&#40;angle&#41;&#41;;
      vesa_putpixel&#40;x,y,img.p_imgbuf&#91;i+j*img.xres&#93;&#41;;
      &#125;

Tady je pak muj programek:
http://www.volny.cz/xfer/4all/rotate2.exe
a obrazek:
http://www.volny.cz/xfer/4all/a1.tga

Rotuje to po 1 stupni se zaplym vsync;

Jo este, u tebe sem koukal, ze ten obrazek taky nevyplnuje celou obrazovku, ac je 320x200 a zkousels co se stane kdyz pred kazdym snimkem smazes VRAM?

**Glottis** · 18.01.2004, 10:10

mazat vram sem nezkousel.

me prijde ze to prave delas obracene nez bys mel, proto ti tam vznikaj ty dirky. ten tvuj algoritmus pocita souradnice kam bude keslit, ne? zkus to obracene. pro souradnici kam kreslit pocitej souradnice co budes kreslit.

kdyby jsi necekal na retrace jak by se to tocilo rychle? 1° je asi 0,017 radianu coz sem tam mel krok take (priblizne, mel sme tam 0,01). tak jestli to je rychlejsi nebo ne.

**RayeR** · 19.01.2004, 00:50

Původně odeslal Glottis

mazat vram sem nezkousel.

Notak si to schvalne zkus. Nejlip indexem 255. Pokud pozadi nemazu, tak
to vypada taky pekne, protoze pod tema dirkama prosvita puvodni obraz takze to nepoznas.

Původně odeslal Glottis

me prijde ze to prave delas obracene nez bys mel, proto ti tam vznikaj ty dirky. ten tvuj algoritmus pocita souradnice kam bude keslit, ne? zkus to obracene. pro souradnici kam kreslit pocitej souradnice co budes kreslit.

Ano pocitam KAM budu kreslit. Nejak nechapu jak by to melo vypadat obracene. Kdyz ted zapomenu na rotaci obrazku, predstav si, ze bych stel nakreslit pouze natoceny obdelnik. Tak bych to udal stejne, akorat budu kreslit konstantni barvou. Pritom tam budu mit "dirky" ale taky.

Napred sem myslel, ze ty svine vznikaj pri zaokrouhlovani float->int

, ze se to tam vlivem naky chyby jako zateteli a padne spatna hodnota. Jak sem ale zistil, tak naky pixely se zas prekryvaji. Ty muzu aspon detekovat (podle toho, ze pred zapisem zkontroluju framebuffer jesi uz tam neni neco zapsano) a tak sem si vypsal jejich souradnice a zistil, ze se zdaleka ne vzdy jedna o cisla s desetinou casti kolem rozhodovaci urovne. Spis me napada, jesi to neni naka nepresnot ty samotny funkce sin a cos.
Kontorloval sem taky jesi mi da x^2+y^2=i^2 to je celkem OK, semtam odchylka asi na 5 des. miste.

Původně odeslal Glottis

kdyby jsi necekal na retrace jak by se to tocilo rychle? 1° je asi 0,017 radianu coz sem tam mel krok take (priblizne, mel sme tam 0,01). tak jestli to je rychlejsi nebo ne.

Bez vsync asi 2x rychlejs, zatim tu rychlost moc neresim, neni to vubec optimalizovany. Do toho se pustim az to bude kreslit korektne.

Jinak tady je este druhej programek, kde to neni nijak vosetreny ty "dirky" http://www.volny.cz/xfer/4all/rotate1.exe

Co je taky zajimavy, ze se to nemeni at pouzivam float nebo long double.

Téma: [asembler] - koprocesor

Nástroje témat

Zobrazení

[asembler] - koprocesor

Informace o tématu

Users Browsing this Thread

Pravidla přispívání