W dniu 2023-02-15 o 19:50, heby pisze:

>> 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?

Nigdy nic nie pisałem w asm (nawet drobnych wstawek). Mój związek z asm
jest tylko taki, że napisałem (lata 90-te) makroassembler dla 8051,
który potem był przez wiele lat używany przez mojego brata (i zapewne
przez wszystkich używających naszego systemu edukacyjnego DSM-51).

A to crc16() to jest moja procedura używana w Builderze. Ona powstała z
przetłumaczenia na C procedury w asm.
Z ciekawości zapisałem ją też wtedy w sposób klasyczny i porównałem
(szybkość i czy wyniki faktycznie zawsze wychodzą takie same :) ).
Ta wyszła szybsza to tamtą usunąłem.

> 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.

Oczywiście masz rację.
Ja tylko napisałem, że bratu (wychowanemu na asm) brakuje w C czasem
pewnych rzeczy, ale nie pisałem, że to znaczy, że C powinno je mieć.
P.G.