WinAvr (avr-gcc) kontra Bacsom-AVR

Reply to
Piotr Wyderski
Loading thread data ...

I niewykluczone ze masz racje. Ale ten programik jest mniejszy, zadnych skomplikowanych operacji :-)

J.

Reply to
J.F.

Ja ci przyznam racje ze pomoca goto mozna narobic takiego bigosu ze sie nikt nie zorientuje jak to zadziala. Ale nie widze powodu dla ktorego rozsadne uzycie mialoby utrudniac - np wlasnie wyjscie z zagniezdzonej petli.

Hm .. jestem w stanie dowolny program zapisac w postaci jednej petli, w ktorej bedzie multum if i pomocniczych zmiennych logicznych. Ciekawe co na to weryfikator :-)

Taa .. tylko juz 8 bajtow pamieci powoduje liczbe stanow przekraczajaca mozliwosci praktyczne dzisiejszych komputerow :-)

Dla nieokreslonej ilosci liczb ?

50minut to znosnie, obawialem sie 50 mln lat :-)

Nawiasem mowiac - quick sort mi sie zawiesil. Podejrzewam ze powodem byla arytmetyka zmiennoprzecinkowa o mantysie innej niz 2 - w rezultacie srednia arytmetyczna dwoch liczb mogla wyjsc mniejsza niz obie liczby, co prowadzi do zawieszenia algorytmu .. chyba Dijkstry ?

J.

Reply to
J.F.

Oj, ale my od pewnego czasu rozmawiamy o zupelnie innym problemie. :-))) Mowa o "robieniu bigosu" przez goto byla w kontekscie prostych algorytmow analizy _przeplywu_. Pozniej rozmowa zeszla na temat analizy _zywotnosci zmiennych_.

Jesli tych zmiennych logicznych bedzie ograniczona liczba (tj. nie bedziesz ich sobie dorabial podczas dzialania programu), to nie uda Ci sie dokonac takiego przeksztalcenia. Rozpoznawanie dowolnego jezyka nieregularnego dla slowa o dlugosci n wymaga Omega(log log n) komorek pamieci, czyli wiecej, niz stalej ich liczby...

Wbrew pozorom one bardzo lubia takie grafy decyzyjne. :-) Powiem wiecej, one czesto w srodku trzymaja sobie opis podanego przez uzytkownika systemu w takiej wlasnie formie.

Jesli sie eksploracji przestrzeni stanow dokonuje metoda brute force, to tak wlasnie jest. Na szczescie wymyslono wiele algorytmow pozwalajacych analizowac za jednym zamachem olbrzymie grupy stanow -- w jaki inny sposob w ciagu 15 lat udaloby sie powiekszyc nasze mozliwosci o 113 rzedow? :-)

Nie dam glowy, ale chyba tak (dawno to czytalem). Tu znajdziesz kilka publikacji na ten temat:

formatting link
Pozdrawiam Piotr Wyderski

Reply to
Piotr Wyderski

Jest sobie darmowy RTOS eCos napisany w asm (HAL), C (wszystkie podsystemy i sterowniki) i C++ (kernel!). Może lepiej rozwijać gotowe rozwiązania ?

Reply to
invalid unparseable

On Mon, 27 Sep 2004 13:39:24 +0200, "Piotr Wyderski" snipped-for-privacy@ii.uni.wroc.pl> wrote: [.....]

IMHO to proste - tzw. "przemysł" nie lubi zmian. A skoro klient nie widzi kodu źródłowego aplikacji, to po co dbać o jego przejrzystość i elegancję jeśli aplikacja działa poprawnie? :-) Poza tym "wszyscy" znają C więc producenci produkują kompilatory i biblioteki C, a skoro producenci robią narzędzia do C, to "wszyscy" uczą się C. I błędne koło się zamyka. A przerwać je trudno bo w powszechnym mniemaniu C++ daje wielokrotnie wolniejszy i pamięciożerny kod wynikowy - ludzie również nie lubią zmian i nie przyjmują do wiadomości że pewne rzeczy się zmieniają. :-) Zobacz np. ile osób rzeźbi w assemblerze tam gdzie z praktycznego punktu widzenia nie ma z tego żadnych korzyści. No i jest jeszcze jedna rzecz - o ile stosnkowo łatwo jest nauczyć się C++, to aby je efektywnie wykorzystywać trzeba zmienić sposób myślenia. A to IMO jest znacznie trudniejsze. Zapewne sam widziałeś wiele programów napisanych w "C z obiektami". :-)

Na wnętrznościach kompilatorów się nie znam, ale jestem przekonany że aplikacja "napisana obiektowo" w C i skompilowana kompilatorem C będzie trochę mniej wydajna niż ta sama aplikacja przepisana na C++. W przypadku nietrywailnej aplikacji kompilator C++ raczej lepiej niż człowiek "zaimplementuje" obiektowość. :-)

BTW. Bez RTTI i dynamic cast można spokojnie żyć, ale wyjątki by się przydały. Oglądałem kod wygenerowany przez g++ i tam try jest rozwijane w wywołanie procedury __cxa_allocate_exception, throw w wywołanie __cxa_throw itp. Jak się domyślam, są to funkcje wbudowane w kompilator. I tak się zastanawiam czy rzeczywiście stanowią one duży problem jeśli chodzi o wymagania szybkościowo- pamięciowe. Bo tak na chłopski rozum to wydaje mi się że one wykonują jakieś szybkie operacje na stosie (alokacja pamięci dla rzucanego obiektu) i ewentualnie wołają konstruktor (w przypadku "rzucania" typów złożonych). Co tutaj może być problemem? Przepełnienie stosu? Przecież takie coś może się zdarzyć nawet wtedy gdy używamy C lub assemblera. I jeszcze jedno - czy w throw/try/catch są thread safe z mocy standardu C++, nie są thread safe, czy też jest to zależne od kompilatora?

Regards, /J.D.

Reply to
Jan Dubiec

Bo to czasem ciekawe nawet :-)

To masz dobrze. U mnie kilka prockow, zadnych AVR :-) wiec co mialem wybrac? C/C++ jest i na procki i na PCty - wiec latwo bylo sie zdecydowac. Zreszta C++ na wieksze procki coraz bardziej mnie zaczyna wciagac - naprawde mocne narzedzie. (Dzieki Piotrowi Wyderskiemu sie tym troche zainteresowalem - warto).

Zalezy jaki program, jaka rodzina prockow, itp, itd... U mnie zwiekszenie kodu ponad 256kB bedzie skutkowac koniecznoscia zmieniania plytki 6 warstwowej (tylko taki RAM tam siedzi).

avr-gcc nie znam, ale skoro gcc to moze... emacs? :-)

Reply to
jerry1111

On Mon, 27 Sep 2004 20:47:28 +0200, point snipped-for-privacy@.org wrote: [.....]

Znamy, znamy. :-) Tzn. teoretycznie ponieważ wielokrotnie studiowałem źródła eCosa, ale nigdy go nie uruchamiałem na żadnym sprzęcie. Ja myślałem o czymś mniejszym, np. czymś w stylu Nut/OSa ale z wywłaszczaniem a nie cooperative multitasking i napisanego w języku wspierającym obiektowość.

Regards, /J.D.

Reply to
Jan Dubiec

On Mon, 27 Sep 2004 22:22:14 +0200, "Jacek \"Plumpi\"" snipped-for-privacy@wp.pl wrote: [.....]

No nie wiem. Zdaje się Knuth powiedział że "premature optimization is the root of all evil". Innymi słowami po prostu lepiej klepać soft jak leci a potem, jeśli okaże się że nie spełnia on wymagań, szukać wąskich gardeł i eliminować je poprzez poprawianie/dobór odpowiedniego algorytmu, struktur danych i na końcu stosowanie sztuczek typu ręczne rozwijanie petli czy też stosowanie wstawek assemblerowych. Oczywiście obecnie odpowiednie algorytmy i struktury danych można dobrać przed rozpoczęciem pisania softu ponieważ można wcześniej przeczytać sobie książkę, np. autorstwa wspomnianego Knutha. :-)

Bascom ma jedną zasadniczą wadę - przesiądziesz się na coś innego niż AVR czy MCS-51 i nie będziesz miał Bascoma. A kompilator C będzie prawie napewno.

W jaki sposób jest składnia ukierunkowana na sprzęt? A jeśli nawet, to jest dobrze ukierunkowana ponieważ sporo softu przeniesionego z jednej platformy na inną da się skompilować bez żadnych modyfikacji. :-)

A to już zależy od aplikacji. Bascom nic nie pomoże jeśli będziesz chciał zaimplementować np. PPP. Bo dominującym czynnikiem będzie tutaj czas poświęcony na studiowanie RFC dotyczących PPP. A jest tego trochę. No i jeszcze trzeba doliczyć czas potrzebny na debugowanie i testowanie - kto wie czy nie dłuższy od tego pierwszego.

Regards, /J.D.

Reply to
Jan Dubiec
Reply to
Piotr Wyderski

On Tue, 28 Sep 2004 02:51:51 +0200, "Piotr Wyderski" snipped-for-privacy@ii.uni.wroc.pl> wrote: [.....]

Wiesz, ja C (bez plusów) używam nie od wczoraj a jednak czasami zadarza mi się odkryć jakąś nowość. :-)

[.....]

Z pewnością. Ale chodziło mi o to że np. po latach "myślenia strukturalnego" ciężko jest przestawić się na coś innego. Ot, taka ludzka natura. Ja np. kiedyś próbowałem trochę pobawić sie w programowanie funkcyjne i nic z tego nie wyszło. :-)

No masz, chyba każdy takie pisał. :-) Tyle tylko że ja zacząłem dostrzegać wady moich pierwszych wypocin nie dlatego że zacząłem się uważać za mistrza C++ (którym zdecydowanie nie jestem) ale po zrozumieniu co to jest OOA i OOD.

[.....]

Ja raz użyłem RTTI gdy rzeźbiłem jakiegoś małego toola używając MFC. :-)

[.....]

No ale dlaczego mają mieć jakieś specjalne tzn. duże wymagania pamięciowe? Czy użycie wątków, z punktu widzenia zapotrzebowania na stos, różni się zasadniczo np. od wywołania pewnej liczby zagnieżdżonych funkcji albo jakiejś nie dającej się zamienić na pętlę rekurencji? No i dlaczego muszą mieć oddzielny stos? Czy nie można zaalokować pamięci dla wyjątków w ramach stosu bieżącego wątku? Taki stos w stosie.

[.....]

No właśnie o tą lokalność chodzi. Czy jest ona wymuszona przez standartd czy też nie. Bo przykro by było gdyby się okazało że po napisaniu większego kawałka wielowątkowego kodu okazało się że implementacja wyjątków w jakimś kompilatorze korzysta jednak ze zmiennych globalnych nie zapewniając przy tym żadnego mechanizmu synchronizacji. :-)

Regards, /J.D.

Reply to
Jan Dubiec

On Tue, 28 Sep 2004 11:51:19 +0200, "Plumpi" snipped-for-privacy@wp.pl wrote: [.....]

No dobrze, to co z tego wynika? Że Bascom jednak "ma składnię ukierunkowaną na sprzęt"? :-)

No przecież właśnie o to mi chodziło. Nawet gdyby Bascom miał niewiadomo jak bogatą biblitekę standartową, to zawsze będzie można znaleźć taką aplikację, gdzie ta biblioteka praktycznie do niczego się nie przyda albo tylko nieznacznie skróci czas tworzenia softu. Tak więc nie można stwierdzić że Bascom jest lekiem na całe zło tego świata. :-) Chociaż zapewne jest znakomity do trywialnych projektów typu "odczytaj temperaturę z czujnika i wyślij wynik na wyświetlacz i/lub UARTa".

Regards, /J.D.

Reply to
Jan Dubiec

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.