W dniu 2019-02-14 o 13:59, Queequeg pisze:
> J.F. <j...@p...onet.pl> wrote:
>
>>> Ale co kompilator może zrobić, jak sam procesor nie obsługuje
>>> atomicznego dostępu do tej zmiennej (bo np. jest 8-bitowy, a zmienna
>>> 16-bitowa)?
>>
>> To samo, co programista ma zrobic :-)
>
> Programista ma kontekst, którego nie ma kompilator. Programista wie, kiedy
> chce mieć sekcję krytyczną (która nie musi obejmować wyłącznie atomicznego
> dostępu do zmiennej szerszej niż magistrala adresowa).
>
>>> Zmienna może się zmienić między każdą z tych instrukcji.
>>
>> Cos w tym jest.
>
> Jest jest... po to są sekcje krytyczne.
>
>>> Czemu? Co ma do tego ARM? Chodzi o szerokość magistrali danych? To
>>> rozwiązuje tylko jeden problem,
>>
>> Tak, problemu z int nie bedzie :-)
>
> Z odczytem int nie, ale np. z read-modify-write już tak.
>
>>> ale inne (chociażby ten pierwszy przykład wyżej) pozostają.
>>
>> Ciezkie jest zycie programisty.
>
> A to swoją drogą... ale raczej przez ludzi a nie przez komputery :)
>
> Trzeba po prostu pamiętać, że (przynajmniej w przypadku C i C++)
> kompilator nie tłumaczy kodu na język maszynowy jeden do jednego. Kod to
> tylko pewien abstrakcyjny opis, który kompilator może traktować z dosyć
> dużą dowolnością. Dochodzą do tego chociażby zagadnienia związane z
> reorderingiem.
>
> Przykładowo:
>
> https://www.nongnu.org/avr-libc/user-manual/optimiza
tion.html
>
> 1. Dzielimy (powolna operacja)
> 2. Wyłączamy przerwania cli
> 3. Zapisujemy wynik dzielenia do zmiennej (szybka operacja)
> 4. Włączamy przerwania
>
> A optymalizator twierdzi, że wyłączy sobie przerwania przed dzieleniem, bo
> tak mu mnieszy kod wychodzi :)
Faktycznie tak robi, na całe dzielenie wył przerwania ale można ten
problem obejść :)

void test2( unsigned int val )
{div_t wynik;
wynik=div(65535U,val);
e10: bc 01 movw r22, r24
e12: 8f ef ldi r24, 0xFF ; 255
e14: 9f ef ldi r25, 0xFF ; 255
e16: 0e 94 f7 08 call 0x11ee ; 0x11ee <__divmodhi4>
return 1;
}

static __inline__ uint8_t __iCliRetVal(void)
{
cli();
e1a: f8 94 cli
//val = / val;
ATOMIC_BLOCK(ATOMIC_FORCEON) {
ivar = wynik.quot;
e1c: 70 93 14 02 sts 0x0214, r23 ; 0x800214 <ivar+0x1>
e20: 60 93 13 02 sts 0x0213, r22 ; 0x800213 <ivar>
return 1;
}

static __inline__ void __iSeiParam(const uint8_t *__s)
{
sei();
e24: 78 94 sei


Da się? da sie :) ale prawda jest taka że trzeba mu cały czas patrzyć na
ręce
czy nam czegoś nadmiernie nie zoptymalizował.


--
Pozdr
Janusz