C++ ośla łączka

Mon Feb 13, 2023 10:26 am   

Piotr Gałka wrote:

Czasami w asemblerze można coś bardziej zwarcie napisać.

Jednak w dłuższej perspektywie, pisanie w asm to strata czasu i proszenie
się o kłopoty; zmienia się platforma i musisz
pisać/testować/poprawiać/testować itd, od nowa.

Jeśli procesor już nie radzi sobie z zagadnieniem to trzeba wziąć większy
procesor zamiast schodzić do asemblera.

jp






--
jp

www.flowservice.pl
www.flowsystem.pl

Tue Feb 14, 2023 4:39 pm   

W dniu 2023-02-13 o 09:26, jacek pozniak pisze:


Zapewne 100% racja, ale ja mówię o kimś, dla kogo assembler był gdzieś
tak od 1983 naturalnym środowiskiem, a C używa tylko od jakichś 15 lat.

Do dziś bratu brakuje w C dostępu do bitu przeniesienia, czy parzystości.
P.G.

Tue Feb 14, 2023 8:06 pm   

W dniu 2023-02-14 o 15:39, Piotr Gałka pisze:

normalnie z C.
Wystarczy z and-ować z odpowiednią maską i mamy np przeniesienie czyli
if (SREG & 0x01) {}.

--
Janusz

Tue Feb 14, 2023 11:22 pm   

W dniu 2023-02-14 o 19:06, Janusz pisze:


Prawdopodobnie to ja tu najwięcej i niepotrzebnie mieszam. Wypowiadam
się w kwestiach, o których nie wiem prawie nic.
P.G.

Tue Feb 14, 2023 11:42 pm   

On 14/02/2023 15:39, Piotr Gałka wrote:

Mała uwaga: standard C w ogóle nie okresla konkretnego sposobu zapisu
liczb typu integer, dając do wyboru trzy różne.

Dlatego tego typu funkcjonalnośc musiała by najpierw zabetonować jeden z
nich (2-complemnet) i określić zachowanie takich bitów w różnych
operacjach i sekwencach operacji.

Co prawda ani jeden znany mi kompilator nie potrafi pracować w czymś
innym niż 2-c, ale standard nie przejmuje się tym, co jest, ale tym, co
możliwe.

Są różne koncepcje aby to zabetonować w standardzie, np:

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2218.htm

Ogólnie, jeśli chcesz dokonywać operacji na poziomie pojedynczych bitów
statusowych cpu, to jest ona zależna od konkretnej implementacji
kompilatora, konkretnego hardware i dostepnych rejestrów.

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ń. To nie ten poziom
abstrakcji.

Wed Feb 15, 2023 4:40 pm   

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


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.


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

Wed Feb 15, 2023 8:50 pm   

On 15/02/2023 15:40, Piotr Gałka wrote:

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?


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



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.

Wed Feb 15, 2023 10:28 pm   

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


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.


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.

Wed Feb 15, 2023 11:14 pm   

On Wed, 15 Feb 2023 19:50:48 +0100, heby <heby@poczta.onet.pl> wrote:

Czyli konkretnie jaki side effect z tym UARTem?

--
Marek

Thu Feb 16, 2023 12:10 am   

On 15/02/2023 22:14, Marek wrote:

Na przykład, w wielu uartach odczytanie bajtu z bufora wejściowego
możliwe jest dokładnie *raz* na każdy odebrany bajt, hardware traktuje
taki odczyt jako procedurę odebrania wiadomości i nastepny odczyt może
odczytać coś z dalszej pozycji bufora. W ogólnym wypadku, operacja na
rejestrze *może* spowodować zmianę stanu hardware. Rejestr to nie jest
pamięć.

Taka ciekawostka: MC68000 i MC68020 rózniły się tym, że pierwszy w
niektórych instrukcjach asm zapisywał *dwukrotnie* to samo do pamieci, a
drugi racz zapisywał a drugi raz odczytywał i w obu wypadkach jedna z
tych operacji była bez sensu algorytmicznego. To cecha magiczna
magistrali 6[8|5]00/68000, każdy cykl jest dostępem do pamięci i
procesor *coś* musi zrobić w każdym cyklu, nawet jak nie miało to sensu,
bo nie miał co wymienić z pamięcią.

Był to spory problem, kiedy okazało się, że jeśli ktoś akurat zapisuje
do rejestru hardwareowego, który ma sideefect np. uruchamiania DMA,
program działał inaczej w zależności od CPU, mimo że efekt końcowy był
identyczny z punktu widzenia ASM.

Ten problem z MC680x0 to sprzętowy odpowiednik "problemów" z C, gdzie
też pewne operacje mogą pojawić się i zniknąc w wyniku optymalizacji, co
nie przeszkadza w modelu pamięciowym, ale może powodować katastrofy w
modelu rejestrów sprzętowych. Dlatego jest słowo volatile. I swoją drogą
tylko dlatego

Thu Feb 16, 2023 1:02 am   

heby <heby@poczta.onet.pl> napisał(a):

Nie tylko. Także na wypadek modyfikacji zmiennej przez procedurę obsługi
przerwania. W głównym programie w ramach optymalizacji zmienna może zostać
skopiowana do rejestru aby obliczenia wykonywać na nim a nie na pamęci. Gdy
w tym momencie pojawi się przerwanie, zmodyfikowana zostanie stara kopia
zmiennej.

--
Grzegorz Niemirowski
https://www.grzegorz.net/

Thu Feb 16, 2023 7:45 am   

On 16/02/2023 00:02, Grzegorz Niemirowski wrote:

Wpadłeś w pułapkę.

Nie.

volatile nie służy do tego.

Do tego, co piszesz, służa bariery/fence.


Jeśli potraktujesz przerwania jako wątki preemptive, to tak naprawdę
piszesz o zagadnieniu dostępu do zmiennych przez kilka watków. Tego
zagadnienia *NIE* należy rozwiązywać za pomocą volatile, ono nie
powstało do tego i sie do tego NIE nadaje.

https://stackoverflow.com/questions/4557979/when-to-use-volatile-with-multi-threading

"Short & quick answer: volatile is (nearly) useless for
platform-agnostic, multithreaded application programming. It does not
provide any synchronization, it does not create memory fences, nor does
it ensure the order of execution of operations. It does not make
operations atomic. It does not make your code magically thread safe.
volatile may be the single-most misunderstood facility in all of C++."

Thu Feb 16, 2023 1:46 pm   

heby <heby@poczta.onet.pl> napisał(a):

Możesz podać przykład na ATmegę?


Wiem. Nic o wątkach nie pisałem.

--
Grzegorz Niemirowski
https://www.grzegorz.net/

Thu Feb 16, 2023 2:20 pm   

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


Akurat brat przyszedł do mnie z pytaniem, jak coś zrobić w C (o tym
dalej bo ja nie znam odpowiedzi ale powiedziałem mu, że zapytam
mądrzejszych ode mnie) więc wspomniałem mu o tym co tu napisałem o bicie
przeniesienia, czy parzystości.

On ma całkiem odmienne zdanie od Twojego.
Nie widzi żadnego problemu, aby w C dla zmiennych całkowitych było na
przykład pojęcie bitu parzystości. Jak procesor go ma to kompilator
korzysta bezpośrednio, a jak nie ma to wtedy wylicza tak jak ja w tej
crc16().
Gdzie tu proszenie się o katastrofę?
A....
Nie wspomniałem mu o różnych reprezentacjach zmiennych o których pisałeś
z czego on (tak jak i ja) całkowicie nie zdaje sobie sprawy. Ale
faktycznie są stosowane jakieś inne reprezentacje?

A teraz pytanie brata na które nie znamy odpowiedzi.

Ogólnie to jest pierwsze podejście do procesorów ARM (nie wiem z którym
w tej chwili walczy (Silabs EFM32PG22..., EFM32PG23..., a może EFM32TG11..).
Zanim użyje procesor po raz pierwszy musi opanować podstawowe działania
no i jest właśnie na tym etapie.

On by potrzebował sizeof(funkcja).

Ale jak próbuje to zrobić to dostaje 1.
Zasugerowałem, że może jak wstawi etykietę (przypomnieliśmy sobie, że
chyba w C coś takiego jest) na nawiasie zamykającym funkcję to uda się
policzyć różnicę między jej adresem a adresem początku funkcji.
Właśnie mi krzyknął (jego pokój jest piętro niżej), że z zewnątrz
funkcji nie ma dostępu do tej etykiety.

Napiszę do czego mu to potrzebne bo czasem może rozwiązanie głównego
problemu robi się inaczej niż on kombinuje.

Wczoraj wieczorem wspólnie tłumaczyliśmy dwa akapity datasheet, czy
manuala (nie wiem - on mi po prostu podświetlił akapit na ekranie i
chodziło o to jak to rozumiemy).

Tam było, że jak się coś robi z programowaniem flasha z wnętrza programu
to ogólnie nie ma gwarancji, że wszystko się uda. I to zdanie było
ogólne - czyli nawet jak ruszasz inną stronę niż jesteś to może coś nie
zadziałać. Nie napisali co dokładnie, ale skoro może coś się nie udać to
my tego nie chcemy. Napisali, żeby przekopiować odpowiednią funkcję do
RAMu, wywołać ją i z niej uruchomić proces kasowania, czy programowania
flasha.

Już opanował wywoływanie funkcji po jej skopiowaniu do RAMu.
Z adresem początku sobie radzi, choć mówi, że wskaźnik na funkcję jest
zawsze większy o 1 od prawdziwego adresu i ustalając fragment do
kopiowania on musi tę jedynkę odejmować.
Wszystko już działa, tylko, że na razie rozmiar funkcji bierze z sufitu
na zapas.

No i jedyne co brakuje do odhaczenia kolejnej funkcjonalności to
ustalenie w jednej funkcji jaki jest sizeof drugiej funkcji.

Może wiesz (lub ktoś inny) jak to się robi.
P.G.

Thu Feb 16, 2023 2:45 pm   

On 16/02/2023 12:46, Grzegorz Niemirowski wrote:

Nie. Bo mowa o C ogólnie. Szczególne dla AVR stosujemy sztuczki
asemblerowe, nielegalne w danej sytuacji słowa kluczowe itd itp. Sam
fakt użycia "przerwania" jest z definicji nieistniejącym bytem w C i
wymaga poza-językowych narzędzi, bo sam język nie dostarcza wsparcia dla
przerwań wiec trudno tez, aby dostarczał mechnizmy ich wspierania.

Uwaga o volatile dotyczy *języka* C a nie implementacji tego na AVR.

Jeśli pytałbyś o ogólny C++ to zasugeroeałbym okolice:

https://mariadb.org/wp-content/uploads/2017/11/2017-11-Memory-barriers.pdf

Czy poprawna implementacja na AVR istnieje - nie wiem. Może kiedyś zerknę.


Mimo to przerwanie jest czymś identycznym z wątkiem preemptive. Ma te
same konsekwencje i dla dużych procesorów, szczególnie wielordzeniowych,
niesie z sobą dokładnie te same zagrożenia, co wątki. I nie jest tak, że
świat kończy się na 8051. Wielordzeniowe procesory embedded to nic
specjalnie dziwnego.

Tam, wszyscy programiści od volatile, wybiją sobie zęby o protokoły
synchronizacji cache, out-of-order execution itd itp.

PS. Zaznaczam, że nic nie pisałeś o AVR w poprzednim poście, wiec w
ogólnym wypadku, volatile nie może i nie powinno być uzywane w celu
synchronizacji zmiannych w przerwaniach. W szczególnym, kiedy znasz
konkretną architekturę, być może.