eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.misc.elektronikaProgramowanie uC - Pascal, czy C ?Re: Programowanie uC - Pascal, czy C ?
  • Path: news-archive.icm.edu.pl!agh.edu.pl!news.agh.edu.pl!newsfeed2.atman.pl!newsfeed.
    atman.pl!goblin2!goblin.stu.neva.ru!feeder.erje.net!us.feeder.erje.net!usenet.b
    lueworldhosting.com!feeder01.blueworldhosting.com!peer02.iad.highwinds-media.co
    m!news.highwinds-media.com!feed-me.highwinds-media.com!nx01.iad01.newshosting.c
    om!newshosting.com!newsfeed.neostrada.pl!unt-exc-02.news.neostrada.pl!unt-spo-b
    -01.news.neostrada.pl!news.neostrada.pl.POSTED!not-for-mail
    Date: Mon, 27 Jan 2014 22:11:16 +0100
    From: Grzegorz Kurczyk <g...@c...slupsk.pl>
    User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101
    Thunderbird/24.2.0
    MIME-Version: 1.0
    Newsgroups: pl.misc.elektronika
    Subject: Re: Programowanie uC - Pascal, czy C ?
    References: <b...@g...com>
    <b...@4...com>
    <e...@g...com>
    <lc4a64$evh$1@node2.news.atman.pl>
    <6...@g...com>
    <52e601a5$0$2227$65785112@news.neostrada.pl>
    <52e6b236$0$2373$65785112@news.neostrada.pl>
    <lc6clu$eb3$1@node2.news.atman.pl>
    <52e6b7c3$0$2137$65785112@news.neostrada.pl>
    <lc6e13$tpq$1@node1.news.atman.pl>
    <52e6c1b6$0$2149$65785112@news.neostrada.pl>
    <lc6h5h$iv8$1@node2.news.atman.pl>
    In-Reply-To: <lc6h5h$iv8$1@node2.news.atman.pl>
    Content-Type: text/plain; charset=ISO-8859-2; format=flowed
    Content-Transfer-Encoding: 8bit
    Lines: 34
    Message-ID: <52e6cb74$0$2206$65785112@news.neostrada.pl>
    Organization: Telekomunikacja Polska
    NNTP-Posting-Host: 80.52.170.66
    X-Trace: 1390857076 unt-rea-b-01.news.neostrada.pl 2206 80.52.170.66:43824
    X-Complaints-To: a...@n...neostrada.pl
    X-Received-Bytes: 3122
    X-Received-Body-CRC: 78832911
    Xref: news-archive.icm.edu.pl pl.misc.elektronika:658850
    [ ukryj nagłówki ]

    W dniu 27.01.2014 21:55, Grzegorz Niemirowski pisze:
    > Grzegorz Kurczyk <g...@c...slupsk.pl> napisał(a):
    >> Zapis ze wskaźnikiem stosowałem w związku z optymalniejszym kodem
    >> wynikowym avr-gcc. Przy konstrukcji Buff[i++] umieszczonym w pętli w
    >> kodzie wynikowym za każdym razem był liczony wskaźnik do i-tego
    >> elementu tablicy. Czyli gdy np elementami tablicy Buff były zmienne
    >> typu long, to w pętli za każdym przejściem było liczone wskaźnik do
    >> elementu wg wzoru ptr = adres_bazowy_tablicy_Buff + i * 4; Przy
    >> zastosowaniu wskaźnika był on ustawiany na adres początku tablicy
    >> tylko raz przed pętlą, a potem wewnątrz pętli inkrementację wskaźnika
    >> załatwiał jeden rozkaz procesora ADIW Z, 4
    >> Pozdrawiam
    >> Grzegorz
    >
    > Hm, to ciekawe. Może to przypadłość konkretnej wersji avr-gcc lub
    > kwestia ustawień kompilacji. Z tego co wiem, współczesne kompilatory na
    > tyle radzą sobie z optymalizacją, że potrafią wygenerować tak samo
    > szybki kod dla dostępu wskaźnikowego jak i tablicowego.
    > http://stackoverflow.com/questions/2305770/efficienc
    y-arrays-vs-pointers
    >

    To nie tylko kwestia kompilatora ale i możliwości procesora. Przykład,
    który podałeś tyczy "dużych" procesorów posiadających rozbudowane tryby
    adresowania (32bitowy procesor z rodziny 686). On potrafi sobie policzyć
    wskaźnik do elementu tablicy w jednym rozkazie i tu faktycznie nie ma
    różnicy. W małym AVR-ku już tak słodko nie ma :-( Wyliczenie wskaźnika
    do elementu tablicy to już kilka rozkazów. A jak tablica ma elementy
    typu rekordowego o "dziwnej" liczbie bajtów w rekordzie, to w
    wyliczeniach wskaźnika pojawia się czasochłonne mnożenie.

    Pozdrawiam
    Grzegorz


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: