Pomysł ciekawy, ja nawet już jakiś czas temu w innym wątku próbowałem też chciałem coś podobnego zrobić, ale na rozwiązanie problemu odpowiedział niestety tylko jeden z kolegów. Zaproponuje go tutaj również, do testu bo jest on ciekawy. Sam problem jest łatwy, ale może powodować nie lada problem (generować duży kod) w przypadku kodu napisanego w C.
Mam jednak pytanie i sugestię co do samego wyniku testu.
Czy porównujemy wielkość i czas potrzebny do wykonanie test od samego początku kodu (resetu procesora)?
Dlaczego o to pytam, jak wiesz za czym procesor wykona pierwszą linijkę naszego kodu, kompilator w kodzie wynikowym umieszcza tablice skoków przerwań, inicjalizację stosu, zmiennych, pamięci itd.
Czasami różnicę, nawet w tym samym kompilatorze, ale miedzy różnymi procesorami są bardzo duże. Przykładowo tablica przerwań miedzy takim archaicznym 90S2313, a amega162 to ze względu na ilość przerwać, oraz w przypadku atmegi trzy bajtowy rozkaz skoku, wielkość początku kodu kilkakrotnie jest dłuży dla 162.
Proponuję, aby jednak tą cześć kody i pracy procesora pominąć, można ewentualnie wykonać osobne porównanie takiej części kodu.
Proponuje, w przypadku kodu, wykonać najpierw kompilację, tzw. pustego programu, w którym były by zawarte tylko zmienne globalne i tą wartość odjąć o wynikowego kodu już całego rozwiązania testu. Podobnie jeśli chodzi o ilość taktów procesora, najpierw określić ile zajmuję taki prolog, zresetować w debugerze licznik i wykonać symulację dla głownego kodu testu.
PS. Ja będę zgłaszał funkcje napisane w bascom i WinAvr
Mam jednak pytanie i sugestię co do samego wyniku testu.
Czy porównujemy wielkość i czas potrzebny do wykonanie test od samego początku kodu (resetu procesora)?
Dlaczego o to pytam, jak wiesz za czym procesor wykona pierwszą linijkę naszego kodu, kompilator w kodzie wynikowym umieszcza tablice skoków przerwań, inicjalizację stosu, zmiennych, pamięci itd.
Czasami różnicę, nawet w tym samym kompilatorze, ale miedzy różnymi procesorami są bardzo duże. Przykładowo tablica przerwań miedzy takim archaicznym 90S2313, a amega162 to ze względu na ilość przerwać, oraz w przypadku atmegi trzy bajtowy rozkaz skoku, wielkość początku kodu kilkakrotnie jest dłuży dla 162.
Proponuję, aby jednak tą cześć kody i pracy procesora pominąć, można ewentualnie wykonać osobne porównanie takiej części kodu.
Proponuje, w przypadku kodu, wykonać najpierw kompilację, tzw. pustego programu, w którym były by zawarte tylko zmienne globalne i tą wartość odjąć o wynikowego kodu już całego rozwiązania testu. Podobnie jeśli chodzi o ilość taktów procesora, najpierw określić ile zajmuję taki prolog, zresetować w debugerze licznik i wykonać symulację dla głownego kodu testu.
PS. Ja będę zgłaszał funkcje napisane w bascom i WinAvr
--= SWL SP6-01-396 =--