To jakie są te chwalone zalety pisania programów na ARM w architekturze v. Neumanna? Przecież tak samo mogę to napisać w AVR. To kompilator dba gdzie umieszcza zmienne a ja je tylko deklaruje. wiec o czym mowa w tych zaletach?
W AVR i np. PIC 8-bit są 2 fizyczne i logiczne przestrzenie adresowe (mogą być pod tym samym adresem startowym): RAM i ROM. Żeby np. skopiować 1 bajt do rejestru ALU trzeba użyć innych instrukcji asemblera (w C może to być niewidoczne) dla RAM i innych dla ROM. W ARM jest bez różnicy bo pamięci są zunifikowane w jedną przestrzeń logiczną.
W dniu 07.11.2009 20:09, slawek7 pisze:
Tylko, ze w przypadku AVR dbaja o to wylacznie kompilatory komercyjne (chyba dbaja), gcc niestety nie i stale zadeklarowane jako const laduja w SRAM zamiast FLASH. Zreszta w przypadku AVR jest dodatkowy problem - inne instrukcje realizuja dostep do SRAM a inne do FLASH, w efekcie trzeba miec dwie wersje. No ale nie ma co narzekac, to sa kompromisy w
8-bitowym mikrokontrolerze. Wprowadzenie ciaglej adresacji spowodowaloby koniecznosc uzycia wiekszych niz 16 bitowe wskaznikow, czyli overkill dla takiego malego procka.
Nie rozumiesz. Zeby dobrac sie do danych, trzeba w AVR uzyc instrukcji LD dla RAM, albo LPM dla programu.
Jesli w programie odwolujesz sie do zmiennych, to kompilator wie gdzie umieszczonych, i uzywa wlasciwych instrukcji.
Ale jesli piszesz funkcje, ktorej parametrem jest wskaznik/adres danej, to ktorego rozkazu ma kompilator uzyc w srodku funkcji ?
Musialby ambitnie program sledzic, zeby wiedziec z adresem do ktorej pamieci jest wywolywana ta funkcja. A przeciez moze byc wywolywana wielokrotnie, ze wskaznikami na oba rodzaje pamieci.
J.
J.F. pisze:
W kompilatorze sdcc dla 8051 przyjęto bardziej uniwersalne rozwiązanie - we wskaźnikach na dane przekazywana jest oprócz samego adresu również informacja o typie pamięci. To niestety zabija sporo wydajności (pobranie jednego bajtu takim wskaźnikiem jest w praktyce wywołaniem funkcji obsługującej różne typy pamięci).
Otoz to. Tez zle.
J.
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.