WinAvr (avr-gcc) kontra Bacsom-AVR

A poza tym w C++ mozna sobie przeciazyc operator new, by zwracal wskaznik na ta "wielokrotnie uzywalna" pamiec, albo jeszcze lepiej uzyc placement new. Zostaw C, to jest tak bardzo przestarzaly jezyk programowania, ze az boli. :-)

Pozdrawiam Piotr Wyderski

Po przejrzeniu kodu po deassembleracji okazało się że kompilator C właśnie tak zrobił, Bascom nie wpadł na ten pomysł :)

Użytkownik mlodedrwale napisał:

Zrobiłem symulację w AvrStudio (pod Win)

Użytkownik WJ napisał:

Nie dokładnie, zauważyłem że GCC jest "sprytny" potrafi pominąć operację które i tak nic nie zmieniają w efekcie działanie programu, oczywiście dobry programista mający dużo czasu nie będzie pisał "nadmiarowego" kodu, niestety przeważnie nie ma zbyt dużo czasu na pisanie programu co za tym idzie na: optymalizację działań matematycznych, doszukiwanie się pewnych zależności itp.

Użytkownik ziel napisał:

To było dla "procesora" 90S2313 (który nie posiada mnożenia).

Taa - a program obslugi nowego operatora zajmie 20 KB :-)

J.

Nie przesadzajmy, w koncu mowa o trywialnie prostym programie, ktory praktycznie na kazdym procku da sie zrobic zgrabnie. Podziwiac mozna co najwyzej kompilator, ze nie skopal..

J.

W ogolnym. Ale zakladamy ze programista jest rozsadny i nie naduzywa ..

Ale one chyba tak maja zyc. Szczegolnie w takich malych prockach, gdzie przerwania sie uzywa.

J.

No w C też dałoby się zoptymalizować ten mój przykład - tak jak napisałem, trzebaby zdefiniowac unię która składałaby się z tych dwóch buforów. To byłoby szybsze od new. Aczkolwiek nieeleganckie. :-)

Hehe, wiem. :-) Od pewnego czasu, w ramach poszerzania horyzontów, chodzi mi po głowie napisanie w C++ małego, opensourceowego RTOS-a na H8 i ARM-y. Myślałem też o Ada, ale tutaj może być klopot z kompilatorem na te platformy. To tyle na temat prywatnych zainteresowań. Natomiast zawodowo (mówimy o zastosowaniach embedded) odejście od C jest prawie niemożliwe. Bo albo nie ma kompilatora C++ dla danego uC, albo kosztuje on ciężką kasę, albo jest kompilatorem C++ tylko z nazwy, albo nawet jeśli kompilator jest osiągalny, to producent urządzenia wykorzystującego dany uC dostarcza tylko biblioteki C.

Regards, /J.D.

On Sun, 26 Sep 2004 23:53:56 +0200, "Thomek" snipped-for-privacy@usunto.poczta.fm> wrote: [.....]

Bo to jest pierwszy z brzegu przykład dobrany tak, aby kompilator za mocno nie zoptymalizował programu.

I sądzisz że wskaźniki pomogą skoro przerwania są nieprzewidywalne? W takim przypadku trzeba użyć jakiegoś mechanizmu synchronizacji. Albo po prostu nie używać współdzielonej pamięci.

Regards, /J.D.

On Behalf Of Maksymilian Dutka

To wytłumacz mi proszę, dlaczego mamy takie duże rozbieżności: Twój BASCOM - kod 418b cykli 2700 Mój BASCOM - kod 156b cykli 1764

Oraz w jaki sposób kod zawierający 158 rozkazów (około) i pętlę wykonującą się 20 razy można wykonać w 178 cyklach? Dla ułatwienia. Procesor w tak prostym programie musi przejść przynajmniej jeden raz przez każdy rozkaz. Jeśli jest inaczej, kompilator generuje wybitnie nadmiarowy kod i nadaje się wyłącznie do śmieci. Pozostaje nam 20 cykli na : skok do początku pętli, wykonanie soft_mnożenia, przesłanie wyniku do portu. Trochę mało.

Ale możemy zrobić zawody. Napisz jakiś większy program w C, a ja go przeniosę na BASCOM. Jestem w 100% pewny, że mój program będzie mniejszy i szybszy od Twojego. Tylko jeden warunek - Twój program musi mieć więcej niż 4kB kodu. Oczywiście nie licząc tablic itp. to ma być program _coś_ robiący. Np. odczyt danych, obliczanie średniej ważonej, przelicznie jednostek, obsługa 2 timerów i ... no w sumie niech to będzie jakiś regulator PID.

pzdr Artur PS Przypuszczam, że jak napiszesz ten program, to przestaniesz zachwycać się C, a zaczniesz doceniać własne doświadczenie.

On Behalf Of Maksymilian Dutka

Bo może autor BASCOM'a zakładał większy poziom inteligencji programisty? A czy dla podstawienia w miejsce stałej=12 zmiennej=12 kod będzie taki sam?

pzdr Artur

On Behalf Of J.F.

ROTFL :-D

a. piwa b. amfy c. kochanki d. innych przyjemnych uzywek. ;-)

pzdr Artur

On Behalf Of J.F.

Ale ja nie ironizuję. Nie znam PICów, tylko że przejrzeniu listy instrukcji wydało mi się trudnym napisanie jakiegoś większego programu w asm.

pzdr Artur

A to niby dlaczego? Jedyna roznica miedzy operatorem a zwykla funkcja bedzie nazwa widzialna przez linker...

Pozdrawiam Piotr Wyderski

To nie jest tak, ze bierzemy dowolny program i sprawdzamy, czy a nuz w jego przypadku sie uda. :-))) Program musi spelniac wiele bardzo silnych ograniczen (np. brak wywolan rekurencyjnych itd.), aby sie dalo na nim uruchomic obecne weryfikatory. Jesli jednak jest on w wymaganej postaci, to wowczas jest gwarancja, ze weryfikator powie o nim wszystko, tj. albo stwierdzi, ze nie ma sciezki prowadzacej do katastrofy, albo jest i wowczas poda sposob jej osiagniecia (kontrprzyklad).

Tak to dziala dla systemow o skonczonej liczbie stanow. Patrzac na problem bardzo pragmatycznie mozna stwierdzic, ze kazdy realizowalny fizycznie uklad elektroniczny ma skonczona pamiec, czyli ma skonczona liczbe stanow, czyli rozpoznaje pewien jezyk regularny. Jezyki te maja te wspaniala ceche, ze chyba wszystkie ich wlasnosci sa rozstrzygalne (tak m.in. dziala sprawdzanie, czy dwa rozne uklady cyfrowe, w tym sekwencyjne, robia to samo).

Wielu ludzi mysli nad weryfikacja systemow o (potencjalnie) nieskonczonej liczbie stanow, tj. o pamieci, ktora nie jest ograniczona przez stala, lecz zalezy od wielkosci danych wejsciowych. Tego w ogolnosci sie zrobic nie da, co wiadomo juz od ~70 lat. Mozna tylko wyszukiwac szczegolne przypadki rodzin takich problemow i do nich konstruowac algorytmy. To sie czesto udaje, np. widzaialem automatyczny dowod spelnialnosci podanych warunkow przez pewna quicksorta. Pojawia sie jednak problem praktyczny: ten program sortowal zaledwie 6-bitowe liczby, a komputer produkowal dowod przez IIRC 50 minut...

No niezupelnie, praktyczny przyklad podal Jan. One maja "sprawiac wrazenie", ze zyja wiecznie, tzn. jesli od pewnego miejsca nie sa uzywane, to mozna je bezpiecznie zabic i wynik wykonania programu nie ulegnie zmianie. Cala zabawa polega na stwierdzeniu tego faktu. :-)

Przerwania niewiele przeszkadzaja -- one nie moga wystapic w dowolnym momencie (traktujac czas jako zmienna rzeczywista), lecz jedynie na poczatku cyklu rozkazowego. Mozna wiec zrezygnowac z przerwan rozumianych doslownie i miedzy kazda instrukcje programu wstawic skok warunkowy do procedury obslugi przerwania, a nastepnie weryfikowac _taki_ program. Przestrzen stanow oczywiscie bardzo puchnie, ale koncepcyjnie niczego to nie zmienia.

Pozdrawiam Piotr Wyderski

Użytkownik ziel napisał:

Z tym że GCC nie bawił się w soft-mnożenie, on sobie przekształcił ten fragment na coś innego :)

Ok :), jak będe miał czas to napiszę i wyślę forum.