szemrany <s...@o...off> wrote:
> Witam
>
> Potrzebuj? przesun?? tablic?/wektor bajt?w w lewo o zadan? liczb? bit?w. Po
> jakim? tam czasie czytania i pr?b zrobi?em prock? opart? o instrukcj? RCL
> przesuwaj?ca o jeden bit:
>
>
> mov ebx, x // liczba bajt?w w wektorze
> mov eax, end_byte // adres ostatniego elementu
> clc
> @@loop:
> mov cl, byte ptr [eax]
> rcl cl, 1
> mov byte ptr [eax], CL
> dec eax
> dec ebx
> jne @@loop
>
> Teraz, gdy chc? przesun?? o 3 bity to wykonuj? ten kod w p?tli trzy razy.
>
> Czy ten kod mo?na zoptymalizowa? bardziej?
> Czy mo?na to zrobi? inaczej, bez RCL?
>

Napisz w C (niekompletne i nieprzetestowane):

carry = 0
for(i = 0; i < n; i++) {
val = *src++;
*dst++ = val<<k | carry;
carry = val>>(M-k);
}

gdzie val i carry sa odpowidniego typu bez znaku, M to ilosc bitow
w tym typie, n to ilosc jednostek do przesuniecia, k to i ile bitow
przesuwamy. Jesli jednostka jest bajt to przy przesuwaniu o jeden
bit ta twoja petla ma szanse byc szybsza (ale RCL to powolna
intrukcja...). Przy przesuwaniu w wiecej niz jeden bit metoda
z dwoma przesunieciami bedzie szybsza. To wyzej moze pracowac
na wiekszych jednostkach, np. po 64 bity. Ta sama metoda
uzywajac SSE pozwala przerobic 128 bitow na krok. Oczywiscie
wtedy jest problem z wyrownywaniem (podzielnoscia adresow
przez 8 czy 16) i koncowka. Ale jak masz dluzsze ciagi to
sie oplaca. Jesli masz troche luzu w pamieci to naprosciej
od razu dzialac na ciagach odpowiednio dlugich slow.

Jeszcze jedno: jak przesuwasz o 0 bitow to ten kod wyzej ma
prawo nie dzialac, po prostu wtedy nalezy kopiowac.

P.S. Jesli koniecznie chcesz w asm, to kompilator Ci powie
jak to wyglada, zreszta recznie tez latwo przetlumaczyc.

--
Waldek Hebisch