On 15/02/2023 15:40, Piotr Gałka wrote:
>> 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.

Programista może być zaskoczony wieloma rzeczami. Czasami jakiś
statement zostanie usunięty, czasami zmieni się kolejność, czasami
mnożenie zmieni się na przesuniecie itd itp, w dodatku zależy to od
flagi -O, dnia tygodnia czy wersji kompilatora.

Przykładowo: wielu niedzielnych programistów embedded jest zakoczonych,
że kompialtor może usunąć im jakiś odczyt z rejestru sprzętowego, jeśli
nie oznaczą go volatile. A to generuje sideeffect, na przykąłd jak
czytamy bufor typu UART.

I nagle chcesz odczytywać wewnatrzny status CPU, co do którego nie ma
nawet pewności, że istnieje na jakiejś architekturze sprzętowej, ani jak
działa w konkretnym przypadku. To proszenie się o katastrofę. Od tej
pory C musiał by być *tylko* na procesory z flagą C i to w dodatku
działającą w jakiś specyficzny sposób. A jak jej nie ma wcale?

> 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;
> }

Dlaczego nie chcesz jej napisać w asm, skoro uważasz, że będzie szybsza
niż wygenerowana przez kompilator?


> W assemblerze ma jeszcze większą przewagę nad zapisem z pętlą bo się po
> prostu korzysta z bitu parzystości.

I dlatego wymagane jest napisanie tego w asm, pod konkretną
architekturę, ze wszystkimi możliwymi na niej sztuczkami. Kompilatory C
są znakomite, ale:
1) programiści embedded często używają jakiejś padliny dostarczonej
przez producentów niszowych, typu KailC, z lat 80, więc kod produkowany
ma się nijak do współczesnych sztuczek z optymalizacją, szczególnie z C++.
2) Jesli C wzbogaciłby się o tak niskopoziomowe detale, znacząco
ograniczyło by to jego abstrakcje w rozumieniu intencji programisty i
dużych optymalizacji. Nie chcemy tego, chcemy mieć abstrakcyjny,
uniwersalny język, a nie język do programowania migania LEDem w 3
cyklach zegarowych na AVR i niczego innego.
3) Istnieje wiele rzeczy które w C nie istnieją, na przykład nie ma
interfejsu do *fence z x86, co powoduje, że wielu ludzi piszących na
systemy wieloprocesorowe (a więc już embedded) jest zaskoczonych jak
działa cache w cpu i że to ma to znaczenie. Nie ma supportu *fence, ale
jest support dla barier, mutexów, lock-free, atomic. Jest to inny poziom
abstrakcji, przez co nie musisz miec nawet architektury z *fence aby
pisać kod poprawny, który będzie działać z dowolną architekturą cpu,
cache itp.

Najzwyczajniej, mylenie C z asm jest nie na miejscu. To nie ten poziom
abstrakcji.