eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.misc.elektronikaZagwozdka w C Keil.Re: Zagwozdka w C Keil - wyjaśnienie.
  • Path: news-archive.icm.edu.pl!news.icm.edu.pl!news.chmurka.net!.POSTED.pi.v.chmurka.n
    et!not-for-mail
    From: q...@t...no1 (Queequeg)
    Newsgroups: pl.misc.elektronika
    Subject: Re: Zagwozdka w C Keil - wyjaśnienie.
    Date: Thu, 14 Feb 2019 12:59:28 +0000 (UTC)
    Organization: news.chmurka.net
    Message-ID: <4...@t...no1>
    References: <q3q59d$hp9$1@node1.news.atman.pl> <q3vee4$o74$1@node1.news.atman.pl>
    <5c63f185$0$476$65785112@news.neostrada.pl>
    <e...@t...no1>
    <y...@4...net>
    <q424f8$8b4$1@node2.news.atman.pl>
    <5c650c2f$0$5597$426a74cc@news.free.fr>
    <5c6544d5$0$486$65785112@news.neostrada.pl>
    <c...@t...no1>
    <5c655b35$0$490$65785112@news.neostrada.pl>
    NNTP-Posting-Host: pi.v.chmurka.net
    Mime-Version: 1.0
    Content-Type: text/plain; charset=ISO-8859-2
    Content-Transfer-Encoding: 8bit
    Injection-Date: Thu, 14 Feb 2019 12:59:28 +0000 (UTC)
    Injection-Info: news.chmurka.net; posting-account="gof";
    posting-host="pi.v.chmurka.net:172.24.44.20"; logging-data="15125";
    mail-complaints-to="abuse-news.(at).chmurka.net"
    User-Agent: tin/2.4.2-20171224 ("Lochhead") (UNIX) (Linux/4.4.50-v7+ (armv7l))
    Cancel-Lock: sha1:vDC6zElc/maZdSUiFxUNrBoTBMk=
    Xref: news-archive.icm.edu.pl pl.misc.elektronika:741027
    [ ukryj nagłówki ]

    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 :)

    Gdy zagłębimy się w optymalizowanie "undefined behavior", to robi się
    jeszcze ciekawiej. Przykładowo:

    #v+
    void fn(int *p)
    {
    int a = *p; // martwy kod
    if (p == 0) return; // nadmiarowe sprawdzenie
    *p = 1;
    }
    #v-

    Spodziewalibyśmy się, że `if (p == 0) return;` nie zostanie usunięte, ale
    ponieważ programista wcześniej dokonał dereferencji, a dereferencja null
    pointera jest UB, to kompilator może usunąć ten drugi, nadmiarowy test bo
    zakłada, że nie ma UB (czyli że p nie może być 0). Moje gcc nie usuwa, bo
    najpierw usuwa martwy kod, ale wcale nie musi -- inna wersja lub inny
    kompilator może zachowywać się inaczej i najpierw usunąć nadmiarowe
    sprawdzenie, a dopiero potem martwy kod.

    Kolejny przykład.

    #v+
    #include <limits.h>
    #include <stdio.h>

    int fn(int i)
    {
    if (i + 1 > i)
    printf("Nie ma integer overflow\n");
    else
    printf("Uwaga: integer overflow\n");
    }

    int main(void)
    {
    fn(INT_MAX);
    return 0;
    }
    #v-

    Kompilujemy z -O0, dostajemy wynik, że jest integer overflow. Kompilujemy
    z -O2, optymalizator stwierdza, że przepełnienie typu ze znakiem jest UB,
    więc usuwa nam ten warunek (ustawia go na true).

    > I co sie dziwic, ze MS w C# zrobil stringi niemodyfikowalne ...

    W C# pisałem coś tylko raz i tylko dlatego, że musiałem :) Zupełnie nie
    moja działka.

    --
    Eksperymentalnie: http://facebook.com/groups/pl.misc.elektronika

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: