Marcin, po naciśnięciu [start debuging] symulator wykonuje cały kod inicjujący (prolog), omijanie wektorów przerwań, ustawienie stosów, zerowanie pamięci RAM itd. i zatrzymuje się na pierwszej linii kodu w języku C. Czyli jeszcze nic z kodu C nie wykonał a już 2,5 tys cykli poszło w powietrze.
Aby mieć pełny wgląd na to co robi procesor należy uruchomić disassembler i na nim robić symulację krok po kroku (po jednej linni kodu asm).
Wynik końcowy jest zapisywany w pamięci RAM do zmiennej FTW (podgląd Memory). Wynik przekazywany jest pośrednio przez rejestry [R21,R20,R19,R18].
Mimo, że mamy 01 kwietnia to wyniki uzyskane w assemblerze nie są forumowym żartem. Nie ukrywam, że wykonanie mojego zadania wymagało w ASM sporego nakładu pracy, brak gotowych procedur obliczeniowych na tak długich formatach. Tym bardziej cieszy uzyskany efekt końcowy. Wynik do sprawdzenia na podstawie symulacji pod AVR Studio, pliki w załączniku.
Uzyskanie dobrego wyniku wymagało zastosowania kilku sztuczek programowych. Obliczenia są wykonywane na poniższych formatach.
- 2^32*f_vfo jako zmienna integer[64] bity;
- dzielenie integer[64] przez integer[32]
- FTW jako integer[32]
Wynik to poprawna część całkowita bez korekty wartości po przecinku.
Wynik końcowy TEST_1, assebmler AVR dla ATmega32
Kod: 162 bajt (8+154) - inicjowanie, program główny, funkcja obliczania FTW
Cykle: 1774 (4+1770)
RAM: 12 bajt - 3 zmienne w RAM po 4 bajty
Wynik: 0x0CCCCCCC
No cóż, interpretację wyników pozostawiam czytelnikom forum. Trudno o lepszą rekomendację dla możliwości assemblera.
