-
Data: 2023-02-15 19:50:48
Temat: Re: C++ ośla łączka
Od: heby <h...@p...onet.pl> szukaj wiadomości tego autora
[ pokaż wszystkie nagłówki ]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.
Następne wpisy z tego wątku
- 15.02.23 21:28 Piotr Gałka
- 15.02.23 22:14 Marek
- 15.02.23 23:10 heby
- 16.02.23 00:02 Grzegorz Niemirowski
- 16.02.23 07:22 heby
- 16.02.23 12:46 Grzegorz Niemirowski
- 16.02.23 13:20 Piotr Gałka
- 16.02.23 13:45 heby
- 16.02.23 13:54 heby
- 16.02.23 14:35 J.F
- 16.02.23 15:23 Grzegorz Niemirowski
- 16.02.23 15:33 Piotr Gałka
- 16.02.23 15:37 J.F
- 16.02.23 16:05 Piotr Gałka
- 16.02.23 17:56 heby
Najnowsze wątki z tej grupy
- System operacyjny dla 6800?
- Przyłączenie działki do sieci elektrycznej
- Działalność nierejestrowana/definicja sprzętu elektronicznego/misie i kolejki
- Smukły, długi ściągacz izolacji do kynaru
- rezystor 3 omy 400W
- [newbie] Jaki multimetr za 2-4 stówy?
- szafka sieciowa
- Raspberry Pi 5 + dyski SATA
- lutownica na węgiel
- Znów czary (albo niewiedza) - tym razem fotowoltaika
- Chess
- Vitruvian Man - parts 7-11a
- przeźroczyste koszulki
- Re: Win 10/11 nie lubi OKI
- Programator czasowy TUYA.
Najnowsze wątki
- 2024-05-18 Warszawa => Mid PHP Developer (Laravel) <=
- 2024-05-18 Warszawa => Software .Net Developer <=
- 2024-05-18 Warszawa => Mid/Senior QA Engineer <=
- 2024-05-18 Ulm => Solution Architect (sichere Kommunikation und IoT-Loesungen <=
- 2024-05-18 Katowice => Head of Virtualization Platform Management and Operating S
- 2024-05-18 Warszawa => SAP WM Consultant / Execution <=
- 2024-05-18 Wrocław => Consultant/Implementer Comarch ERP XL <=
- 2024-05-18 Gdańsk => Head of International Freight Forwarding Department <=
- 2024-05-18 Warszawa => Account Manager (Recruitment Services) <=
- 2024-05-18 Łódź => Salesperson - CRM Systems <=
- 2024-05-18 Łódź => Handlowiec - Systemy CRM <=
- 2024-05-17 ZŁOMNIK o pracy w TVN TURBO, nowych przepisach i współczesnej motoryzacji. Turbo Taryfa!
- 2024-05-17 Białystok => DevOps Engineer Conexa First (Contractor) <=
- 2024-05-17 Warszawa => Starszy inżynier oprogramowania (Rust) <=
- 2024-05-17 Zabrze => Junior HelpDesk <=