Użytkownik "Michoo" <m...@v...pl> napisał w wiadomości
news:ii6h1t$djb$1@news.onet.pl...

>> a) co jest zrzucane na stos i dlaczego w takiej kolejności,
> Jakie to ma znaczenie w kodzie C?

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.

> Chyba, że się operuje na bitach... Poza tym jest to okropny styl pisania -
> komunikację z przerwaniami zawsze lepiej objąć w ATOMIC, bo inaczej łatwo
> o prosty błąd przy późniejszych przeróbkach kodu. (A koszt zazwyczaj
> pomijalny - 2 cykle +1 cykl opóźnienia.)

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.

>> g) że znacznie lepiej mnożyć/dzielić przez 2, 4, 8 itd., niż przez 10.
> Dlaczego? Jeżeli procesor ma układ sprzętowego mnożenia to jest to jeden
> cykl różnicy. Dzielenie przez stałą sensowny kompilator zamienia na
> mnożenie.

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.

>> I wiele, wiele innych rzeczy o których w tej chwili nie pamiętam.
> I wiele, wiele innych rzeczy o których programista C _nie musi_ pamiętać.

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.