książka o programowniu AVR w C

i to zapewne znajdzie w tej książce... EOT

W tym celu trzeba sprawdzić w dokumentacji kompilatora co ląduje na stosie przy danej konwencji wywołań.

Jakie to ma znaczenie w kodzie C?

Ale to wynika z dokumentacji a nie ze znajomości asm. Można napisać w assemblerze adresujący IO pośrednio i tak samo się zastanawiać dlaczego nie działa.

To jest w dokumentacji przy opisie rejestru. To czy blokować, czy nie jest niezależne od tego czy asm czy c.

Hasło: Division by invariant integers using multiplication

Ale ja nie twierdzę, że nie trzeba wiedzieć co się robi, tylko, że wiedza wynikająca z programowania w ASM nie jest konieczna.

P.S. Pisanie na początku w asm potrafi zostawić brzydkie nawyki jak przesunięcia binarne zamiast dzielenia, czy "optymalizację" liczników w pętlach, które nie mają praktycznego znaczenia a zaciemniają kod. Imo optymalizować należy jeżeli są problemy z wydajnością a nie "na zapas".

I w dokumentacji procesora jaki ten stos moze byc.

Na przyklad okresla co jest niemozliwe czy tez bardzo pracochlonne. Pamietasz 51 z jej pamieciami ?

Jak juz znasz dokumentacje na takim poziomie to znasz i asma

albo nie mozna, bo nie ma takiego rozkazu. Przy czym latwiej da sie przeczytac w opisie konkretnej instrukcji niz sie zastanawiac o co temu glupiemu kompilatorowi chodzi przy banalnej instrukcji out(p,v).

C moze to kompilowac inaczej niz myslisz.

O ile pamietam wyniki nie zawsze sa calkowicie zgodne.

No, polemizowalbym nieco czy to brzydki nawyk. Za to brak w C operacji "obrotu" bitow, i to juz jest czasem problem.

Od procka zalezy, bo jak sie ma 16 rejestrow po 32 bit to sie pisze fajnie, a jak trzy po 8 to kompilator musi sie bardzo mocno wykazac, a i programista, zeby sie nie okazalo ze zapasu nie ma :-)

J.

Użytkownik "Michoo" <michoo snipped-for-privacy@vp.pl napisał w wiadomości news:ii6h1t$djb$ snipped-for-privacy@news.onet.pl...

Takie, że jak się pisze w C na scalaki typu Tiny13, które mają "aż" 64 bajty RAMu to się można zdziwić, jaką sieczkę odwala (a raczej odkłada na stos) kompilator C wchodząc w przerwanie. A zasada jest prosta zrzuca się na stos SR i używane w przerwaniu rejestry, a nie wszystko co się da na zapas jak robi to kompilator C.

Tak, szczególnie jak masz np. 1K Flash-a i 64B ramu :) Ale wtedy co robi programista w C? Zamiast ATtiny13, ładuje się ATtiny2313 i problem rozwiązany.

Po pierwsze zajmuje 2 takty samo mnożenie, ale jego wynik ląduje w rejestrach R0/R1, co powoduje, że tracimy nast. kilka taktów aby je stamtąd wydobyć. A przypominam, że R0-R15 są rejestrami w pewnym stopniu upośledzonymi i nie wszystkie instrukcje dostępu do nich działają (np. ldi). Rolowanie zajmuje jednak mniej.

Do momentu jak mu się program "zesra", bo stos wlezie na zmienne.

Podsumowując - pisanie w C wymaga sporo mniej czasu, jednak pewne rzeczy dostępne w asm od ręki C ma wyjątkowo upierdliwie rozwiązane (np. dostęp do zmiennych w pamięci FLASH). Poza tym, jak ktoś zna assembler, to sobie ze wstawkami w newralgicznych miejscach poradzi.

To bug w kompilatorze jeśli wrzuca za dużo. Nikt nie twierdzi ze avr-gcc jest doskonały bo sam wiem że *za* dużo rejestrów używa w przerwaniach.

Kompilator C tak nie robi. Tak robi tylko *zły* kompilator C.

I ma wiele racji. Dla $0.50 oszczędności per sztuka może sie okazać że nie ma co robić rekodzieła w kodzie asm przez 4 miesiące aż się

*zmieścisz* co do bajta tylko od razu wziąść na zapas i program napisać w dwa wieczory.

Jesli kompilator nie potrafi zamienić a *= 2; na operacje shift bitów to jest marnym kompilatorem.

Zapewne asm jest tak magiczny że to się nie ma prawa popsuć w ten sposób, nie?

To raczej brak supportu ze strony kompilatora. C nie ma nic do tego że są jakieś rózne pamięci, choć było by miło gdyby miał.

Rzecz w tym że:

a) niektórzy programisci starej daty w C piszą dokładnie tak samo jak w asm (wlacznie z uzywaniem goto). Dla nich nie ma różnicy bo i tak nie potrafia w gruncie rzeczy wykorzystać C.

b) niektórzy uważają że wstawką może być cały program.

Wiec jest kwestią zdrowego rozsądku sensownie to podzielić. Osobiście jestem zdania że najlepszy jest podział 100% C++ i 0% asm.

Rozwój informatyki w sprzęcie i oprogramowaniu śledzę od czasów ZX spectrum,

5051, Z1, ...

Zawsze zastanawiała mnie pewna sprawa. Jeżeli program który chodził na kompie XT (procesor intel 86 , zegar coś około 4 MHz) uruchomimu na komputerze nowszej generacji ( AT - Intel 286) to wynik działania programu otrzymamy relatywnie szybciej.

Biorąc pod uwagę postęp geometryczny w rozojwu sprzętu obecne komputery klasy PC powinny śmigać w zastraszającym tempie.

Ale co ciekawe cały przyrost mocy obliczeniowej skutecznie konsumowany jest przez rozdmuchane oprogramowanie zarówno systemowe jak i aplikacje. Wiadom, że kiedyś programy były toporne i robiły jedynie to co się od nich oczekiwało. Teraz program musi się jakoś prezentować - nie wystarczy sam wynik obliczeń. Liczy się forma przekazu.

Ale czasami wk...wia mnie do białości sytuacja gdy np instaluję drukarkę gdzie sterowniki do niej zamieszczone są na dwóch płytach DVD. Choć wiem, że wystarczą góra dwa pliczki dll + inf i po sprawie. Ale zwykłemu userowi ciągle sprzedaje się kit, że tak ma być. Że instalacja musi trwać 2 godziny, żę musi zainstalować sobie całe to gówno, że musi podać dane osobowe swoje, szefa i strukturę produkcji firmy oraz obowiązkowo zamówić oryginalne materiały eksploatacyjne.

Odbiegam od tematu ... A chciałem tyko napisać o oprogramowaniu. Patrząc na teorię oprogramowania i twory jakie trzeba póżniej eksploatować często się bebechy gotują. Najczęściej jest to niestety przerost formy nad treścią.

Złożonośc rozwiązaywanych problemów również rośnie w zastraszającym tempie.

On 2011-01-31 16:38, J.F. wrote: [.....]

Tzn. rzeźbiarz w assemblerze nie musi wiedzieć takich rzeczy? :-)

Każdy programista systemowy musi mieć jakieś pojęcie o sprzęcie. I to nie tylko o CPU/MCU ale również musi wiedzieć np. jak wygląda mapa pamięci czy też w jaki sposób są podłączone i jak się komunikują z MCU peryferia, np. jakiś RTC na I2C. Poza tym żaden programista systemowy rzeźbiący w C dla MCU raczej nie uniknie chociażby szczątkowego kontaktu z assemblerem. Natomiast rzeźbiarstwo w assemblerze "dla zasady" najzwyczajniej w świecie nie jest uzasadnione ekonomicznie.

Użytkownik "Sebastian Biały" snipped-for-privacy@poczta.onet.pl> napisał w wiadomości news:ii74kc$sig$ snipped-for-privacy@news.onet.pl...

Ale jak piszesz w asm to z pewnością wiesz co to stos, tym bardziej, że sam musisz go sobie ustawić na RAMEND (lub tam gdzie ci wygodnie), bo nikt tego za Ciebie nie zrobi. Tak samo jak mogę sobie wpisać pod jakiś adres w RAM-ie (gdzie planowany jest koniec stosu) jakąś wartość i nawet podczas wykonywania programu sprawdzać, czy stos tego nie zamazał. Natomiast jestem przekonany, że istnieje niezerowy odsetek osób, które zaczynały przygodę od C, czy co gorsza BASCOM-a używają w swoim programie przerwań na zasadzie dołączania gotowych bibliotek, czy wywołań rekurencyjnych, zbytnio sobie nie zdając sprawy, że takie coś istnieje, a jak nawet słyszał ten ktoś magiczną nazwę "stos", to ma mgliste pojęcie jak działa.

On 2011-01-31 21:04, Sebastian Biały wrote: [.....]

A żeby było śmieszniej, to wkrótce marketingowcy wymyślają nowy "feature" który wymaga delikatnej zmiany softu i znowu jakiś człowiek który kosztuje firmę $2.5k+/miesiąc spędza miesiąc w poszukiwaniu kilkunastu bajtów wolnej pamięci. :-) Przykład z życia wzięty. :-) Po jakimś czasie sytuacja się powtarza. A to wszystko dzięki strategicznym decyzjom oszczędnościowym podczas gdy skala produkcji nie uzasadniała takiej "optymalizacji". :-)

Jasne. A prowadzi to do tego, że mój komputer ma 2 GB pamięci RAM i obecnie zajętość wynosi 89% - a to oznacza, że będę musiał znów zamknąć przeglądarkę i odpalić ją ponownie, bo autorom Firefoksa od samego początku nie udaje się opanować problemu nadmiernej żarłoczności zwierzaka i 1.5GB RAM zabiera mi własnie Firefox po 3 dniach pracy komputera non-stop. Ale kto by się przejmował tymi gigabajtami? User se dokupi...

Może to i ucieczka od (nieciekawego) tematu, ale zaczęła się ciekawa dyskusja. Powiem tak - skończyłem informatykę (taką specyficzną) i o informatykach mam jak najgorsze zdanie. Większość z nich trudno nazwać inżynierami, zresztą sami wolą inne określenia. Bardzo łatwo jest napisać coś co "działa" i ładnie wygląda teraz, ale przypomina to trochę składanie z klocków bez większej znajomości tychże. Dyskusja jest trochę o asm, ale to nie ten poziom - przeciętny informatyk parę lat po studiach reaguje na C nerwowym śmiechem i pytaniem 'po co to komu'?

Użytkownik "kk" snipped-for-privacy@a.pl napisał w wiadomości news:ii7552$dpd$ snipped-for-privacy@news.vectranet.pl...

W tym momencie przychodzi mi na myśl Volkow Commander (VC) napisany w 100% w ASM który zajmując 47KB dawał więcej radości i pożytecznych funkcji niż oryginalny pakiet Nortona Commandera gdzie sam tylko ten commander wymagał około 512KB. Tego się nie dało trzymac na dyskietce wspólnie z systemowymi plikami DOSa więc trzeba było mieć dwie dyskietki. Tymczasem VC spokojnie na luziku nadawał się nawet do uruchomienia w pamięci wysokiej za pomocą Load High i nie zagracał konwencjonalnej :)

Marek

No wiesz, odpowiednio duzy program zawiera stala ilosc bledow - jedne usuwaja, inne dodaja. Nie daje sie tego uniknac.

A spojrz od drugiej strony - jaki to skomplikowany program ten Firefox. Takie czasy.

J.

Widze jakies nieporozumienie.

Oczywiscie niezaleznie od jezyka dokumentacje trzeba przeczytac. A jak sie przeczyta to juz sie umie pisac w asmie, i do tego pije :-)

Aczkolwiek pewne kwiatki czlowiek zauwaza dopiero wtedy jak usiluje cos rzeczywiscie napisac.

J.

oj, ostatnio pomagalem pisac prace dyplomowa - office jest potrzebny, a duzo mu jeszcze brakuje do szczescia, wrecz bardzo duzo :-)

wnosza wnosza, choc to drobiazgi ktore powinny dzialac od poczatku. Tzn ja zauwazam drobiazgi, w srodku jest pewnie wiecej zmian.

Ale niestety - windows przyzwyczailo (tu w sensie dosc pozytywnym), klienci wymagaja rozbudowanych programow, a potem programisci maja co robic przynajmniej na trzy wersje.

J.

Użytkownik "4CX250" <taunusmtv@poćta.łonet.pl> napisał w wiadomości news:4d47b7c4$0$2455$ snipped-for-privacy@news.neostrada.pl...

A mi przychodzi do głowy Racal-Redak, który udawało się odpalić na PC-XT (640kB RAM) z jednym drivem 320kB i bez HD. Trzeba było zrobić RAM-dysk chyba rzędu 180kB (ani więcej ani mniej) i czasem przekładać dwie dyskietki w drive. Zaprojektowałem tak w 1988 roku 2-stronną (względnie dużo elementów w DIP) płytkę jakieś 15cm x 25cm. To był tester, który używaliśmy jeszcze w 2004 aż do momentu wejścia Unii i CE. Porównałem wtedy kiedyś prędkość autoroutera Racal-Redaka i Protela (na jakimś małym ale złośliwie połączonym przykładziku). To, co Protelowi zajmowało n minut Racal-Redakowi zajmowało n sekund i wynik był lepszy. Protel tracił na tym, że wszystko, o czym myślał namiętnie pokazywał na ekranie (i nie dało się tego wyłączyć). P.G.

Można zapytać jaki system? Ja miałem takie piki dopóki nie wyłączyłem wtyczki flash.