W dniu 2023-02-14 o 22:42, heby pisze:

> Co z grubsza oznacza potrzebę napisania tego w asm.
>
> I tak powinno być.
>
> C nie jest od dłubania po bitach na poziomie arytmetyki asemblera,
> ponieważ stabilność bitu przeniesienia może być związana z
> optymalizacjami czy kolejnością wykonywania wyrażeń.

Tak jak kompilator wie, że optymalizując nie może zrobić najpierw
dodawania a potem mnożenia tak mógłby wiedzieć w którym momencie
wymagane jest wyłuskanie określonego bitu.

> To nie ten poziom abstrakcji.

Na pewno masz rację, ale na przykład skorzystanie z bitu parzystości
uprościło by zapis i przyspieszyło działanie procedury:

int crc16(byte* buf,int n,int crc)// doliczenie n bajtów bufora
{ // Polynomial = x^16+x^15+x^2+1
crc&=0xFFFF;
while(n--)
{
int d=((*(buf++))^crc)&0xFF; // lower crc part
int p=d^(d>>4); p^=p>>2; p^=p>>1; // parity bit
crc= (crc>>8) ^ (d<<7) ^ (d<<6) ^ ((p&1) ? 0xC001 : 0);
}
return crc;
}

Kiedyś dawno (w ubiegłym wieku) sprawdzałem, że działa szybciej niż
standardowy zapis z wewnętrzną pętlą obracania bajtu bit po bicie mimo
konieczności wieloetapowego uzyskiwania bitu parzystości.
W assemblerze ma jeszcze większą przewagę nad zapisem z pętlą bo się po
prostu korzysta z bitu parzystości.

Wtedy szybkość liczenia crc wydawała nam się ważna. Jak potem doszło
szyfrowanie i podpisywanie danych w ramce to czas obliczania crc stracił
na ważności :)

Jestem prawie pewien, że brat sprawdzał, czy kompilator kompilując na
8-bitowy procesor się zorientuje, że całą jedną linijkę może pominąć i
skorzystać z bitu parzystości i prawie na pewno mimo włączonych
wszystkich optymalizacji nie zorientował się.
P.G.