Autor: Michal Jankowski (michalj_at_fuw.edu.pl)
Data: Wed 02 Apr 1997 - 10:55:57 MET DST
KARPIO_at_golem.umcs.lublin.pl (Andrzej Karpinski) writes:
> "dana" jest to pelne 64 bity informacji, chociazby o obrazie (czyli np.
> 4ry pixelki z 16-bitowa glebia koloru). zaladowanie tych danych do
> rejestru (8miu pizxeli obrazu z 16 bit kolorem) zajelo 2 takty!
>
> dalej:
>
> powtarzamy te operacje dla drugiego rejestru. poniewaz operacje nastepuja
> bezposrednio po sobie i dotycza roznych rejestrow rzeczywiscie mozna
> wykonac je jednoczesnie. mamy wiec po dwoch taktach zaladowane do
> rejestrow koprocesora 8 pixli z 16-bitowym kolorem.
>
> i teraz (!) - XORujemy przez siebie te dwa rejestry, co zajmuje (!) dwa
> takty. wynik dostajemy np. w trzecim rejestrze. co to daje? ano mamy
> przenikniecie sie 16-bitowych obrazow, wykonane dla 8 pixli dwoch
> roznych obrazkow, ktore zajelo nam... 4 takty!
>
Zara, zara.
Znaczy, tak naprawde jest instrukcja XOR na 64 bitach, tak? Bo
przeciez to, ze te 64 bity traktujemy jako 32*2, albo 16*4, albo 8*8,
to jest rzecz calkowicie umowna i nie zmieniajaca nijak operacji XOR,
ktora i tak sie robi dla kazdego bitu z osobna.
To po co gadac o instrukcji, ktora operuje na kilku danych naraz...
No, chyba ze sa instrukcje MMX, dla ktorych podzial tych 64 bitow na
kawalki ma jakies znaczenie. Ale na razie takiego przykladu nie
podales.
MJ
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 16:00:47 MET DST