Zelety architektury Von Neumannna w uC ARM?
slawek7
Mam do Was prośbę. Wytłumaczcie mi coś.
Jakie są wady i zalety architektury Von Neumanna w uC ARM np
AT91SAM7256.
Ostatnio słyszałem o takim stwierdzeniu że ta architektura ma same
zalety w pracy uC a porównaniu do architektury Harwardzkiej stosowanej
w AVR'ach.
Nie było jednak wyjaśnienia tego.
Możecie mi wytłumaczyć o co tu chodzi. Ja rozumiem że Von Neumanna to
połączenie pamięcie danych i programu w jedną ciągłą ale co mi to daje
jako programiście.
Przecież pisząc jakiś program w C deklarujemy sobie zmienne i tak za
bardzo nie wnikam gdzie ona jest lokowana. Mam zmienną i z niej
korzystam.
Może jestem trochę laikiem, ale nie za bardzo to rozumiem proszę Was o
pomoc w ogarnięciu tego.
J.F.
>Mo�ecie mi wyt�umaczy� o co tu chodzi. Ja rozumiem �e Von Neumanna to
>po��czenie pami�cie danych i programu w jedn� ci�g�� ale co mi to daje
Nie musi byc ciagla. Ma byc jednolicie adresowana i dostepna.
>jako programi�cie.
>Przecie� pisz�c jaki� program w C deklarujemy sobie zmienne i tak za
>bardzo nie wnikam gdzie ona jest lokowana. Mam zmiennďż˝ i z niej
>korzystam.
Korzystasz, bo zmienna z definicji jest w pamieci danych.
A co ze stalymi, np napisami ?
Skad printf ma wiedziec ze podany adres odnosi sie do pamieci programu
a nie danych ?
W praktyce klopotow nie ma duzo .. no chyba ze przenosisz stary
program na harwardzka architekture.
J.
slawek7
>
No tak ale co mi to daje. Jakie są z tego korzyści? Jakiś przykład, bo
trochę tego nie rozumiem.
J.F.
>> Nie musi byc ciagla. Ma byc jednolicie adresowana i dostepna.
>
>trochďż˝ tego nie rozumiem.
No pisalem - skad printf ma wiedziec czy dane, ktorych adresy sa
przekazane w parametrach, pobierac z pamieci programu czy z pamieci
danych ?
Inny slowy - albo wszystkie stale przepiszesz z ROM do RAM .. i
zabraknie RAM, albo bedziesz mial kilka roznych prinft .. a takze
kilka roznych wersji twoich wlasnych funkcji, ktore maja ten sam
problem. A im bardziej zaglebione wywolania tym bardziej sie
komplikuje.
J.
Waldemar Krzok
troche mieszasz, a nawet bardziej niz troche. TY nie musisz nic robic, to ma
zrobic kompilator, chyba, ze to ty piszesz kompilator. W architekturze
v.Neumanna tez masz np. segmentacje i problemy gdzie sa stale, gdzie
zmienne lokalne, a gdzie globalne. Architektura Harvard w ogolnosci pozwala
na szybsze przetwarzanie, bo magistrale danych i programu sa rozdzielone.
Architektura v.Neumanna pozwala na uproszczenie kompilatorow dzieki
wykorzystaniu ortogonalnosci. Oprocz tego latwiej jest pisanie programow AI
wykorzystujacych programy samoadaptacyjne (np. lisp), ale to tylko takie
male duperele. Glowna zaleta v.N. jest prostsza architektura, lepiej
wykorzystujaca zasoby, H. jest bardziej skomplikowana, ale teoretycznie
szybsza.
Waldek
J.F.
>J.F. wrote:
>> Inny slowy - albo wszystkie stale przepiszesz z ROM do RAM .. i
>> zabraknie RAM, albo bedziesz mial kilka roznych prinft .. a takze
>> kilka roznych wersji twoich wlasnych funkcji, ktore maja ten sam
>> problem. A im bardziej zaglebione wywolania tym bardziej sie
>> komplikuje.
>
>troche mieszasz, a nawet bardziej niz troche. TY nie musisz nic robic, to ma
>zrobic kompilator, chyba, ze to ty piszesz kompilator.
Mozna. Tak robil bodajze Keil na '51.
Efekt - przydaje w 1% programu, a wydajnosc spada w calym.
W sumie masz racje - to nie zalezy od architektury magistral, tylko od
realizacji dostepu - identyczny czy rozny.
>W architekturze
>v.Neumanna tez masz np. segmentacje i problemy gdzie sa stale, gdzie
>zmienne lokalne, a gdzie globalne.
Tylko pytanie czy z punktu widzenia programu dostep jest inny, czy sa
tylko drobne klopoty, typu 6 modeli pamieciowych C na 8086.
>Architektura Harvard w ogolnosci pozwala
>na szybsze przetwarzanie, bo magistrale danych i programu sa rozdzielone.
Jesli chodzi o hardware ... to sie ostatnio skomplikowalo i rozmylo.
J.
Artur Lipowski
> Cze��.
> Mam do Was pro�b�. Wyt�umaczcie mi co�.
> Jakie sďż˝ wady i zalety architektury Von Neumanna w uC ARM np
> AT91SAM7256.
> Ostatnio s�ysza�em o takim stwierdzeniu �e ta architektura ma same
> zalety w pracy uC a por�wnaniu do architektury Harwardzkiej stosowanej
> w AVR'ach.
...
Akurat tak si� sk�ada, �e ani ten ARM ani AVR-y nie s� klasycznymi przyk�adami
ww architektur. Dodatkowo s� to zupe�nie r�ne klasy procesor�w, wi�c ich
por�wnywanie, i to w kontek�cie architektury, ma niezbyt du�y sens.
Za to por�wnywanie z punktu widzenia programisty (C) jest IMHO ca�kiem ciekawe.
"Prawdziwa" architektura typu Harvard umo�liwia jednoczesny dost�p do danych i
programu (ze wzgl�du na w pe�ni rozdzielone magistrale). Pozwala to lepiej
wykorzysta� cykle procesora - w tym samym czasie mo�na pobiera� dane do
aktualnego rozkazu i nast�pny rozkaz. Oczywi�cie, aby takie mo�liwo�ci w pe�ni
wykorzysta� procesor musi mie� odpowiednio "sprytny" zestaw rokaz�w, jednostk�
wykonawcz� z potokiem (pipeline) i kompilator, kt�ry wygeneruje odpowiedni kod.
Architektura von Neumann-a pozwala w za�o�eniu na budow� prostszych procesor�w
(tylko jedna magistrala). Jednak obserwuj�c ostanie trendy np. w x86, to ta
"prostota" gdzie� wyparowa�a i mamy skompliwany procek, z tak� sobie wydajno�ci�
(przeliczniki typu liczba operacji/wat lub liczba wat�w na MHz s� raczej kiepskie).
Wydaje si�, �e w embedded nowsze rozwi�zania id� raczej w stron� architektury
typu Harvard np. Cortex, MIPS, procesory DSP.
Pozdrawiam,
--
Artur Lipowski
slawek7
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?
Sebastian Biały
> Mam do Was pro�b�. Wyt�umaczcie mi co�.
> AT91SAM7256.
VN:
a) mo�liwo�� wykonywania kodu z RAM, samomodyfikuj�cy sie kod (np
dynamiczne ladowanie kodu z karty SD itd).
b) brak osobnych instrukcji dostepu do r�nych obszarow pami�ci i I/O -
tak s� skonstruowane wsp�czesne kompilatory jak gcc.
c) w kodzie char* p = "fff" oznacza to samo bez wzgledu na to gdzie
fizycznie jest "fff", ten sam kod b�dzie wysysal dane z RAM i FLASH.
d) mo�liwo�c tworzenia pami�ci wirtualnej w standardowy spos�b (bo mo�na
wykonywac kod w ram).
H:
a) podobno latwiej si� implementuje wi�c ta�sze chipy
b) szybsze, bo mo�na w jednym cyklu mie� dwa r�ne elementy (opcode +
dana z ram).
c) dziwaczne kompilatory i/lub workaroundy na istniejace kompilatory
d) przeginanie niekt�rych w kierunku weso�ych koncepcji jak sprzetowe
stosy itp co uniemo�liwia prac� wielu kompilator�w i w og�le koncepcji
(preemptive multitasking na PICach nie jest chyba mo�liwy).
> Przecie� pisz�c jaki� program w C deklarujemy sobie zmienne i tak za
> bardzo nie wnikam gdzie ona jest lokowana. Mam zmiennďż˝ i z niej
> korzystam.
Niestety nie. Kompilatory C powstawaly w czasach gdy nie bylo do ko�ca
jasne jak odr�ni� r�ne rodzaje pami�ci i czy to w ogole potrzebne.
Efektem czego co kompilator na embedded to wlasne koncepcje jak okresliďż˝
"ten string ma by� we Flash, a ten w RAM". Mamy wi�c mase workaround�w na C.
Du�e systemy najcz�ciej s� VN, ma�e H. Ale cie�ko pokaza� tak� granic�.
Sam widzisz ze ma�y ARM7 jest VN.
Name
> 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�.
T.M.F.
> 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?
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.
--
Inteligentny dom - http://idom.wizzard.one.pl
http://idom.sourceforge.net/
Teraz takze forum dyskusyjne
Zobacz, wyslij uwagi, dolacz do projektu.
J.F.
>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?
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.
Adam Dybkowski
> Jakie sďż˝ wady i zalety architektury Von Neumanna w uC ARM np
> AT91SAM7256.
> Ostatnio s�ysza�em o takim stwierdzeniu �e ta architektura ma same
> zalety w pracy uC a por�wnaniu do architektury Harwardzkiej stosowanej
> w AVR'ach.
> Nie by�o jednak wyja�nienia tego.
> Mo�ecie mi wyt�umaczy� o co tu chodzi. Ja rozumiem �e Von Neumanna to
> po��czenie pami�cie danych i programu w jedn� ci�g�� ale co mi to daje
> jako programi�cie.
Mo�esz za�adowa� plik (do pami�ci danych) i wykona� go jako program.
Taka z gruntu prosta operacja jest kompletnie niemo�liwa np. w
procesorach AVR z architekturďż˝ harwardzkďż˝.
Druga sprawa to dost�p do danych - np. w funkcji printf podajesz jako
pierwszy parametr adres ci�gu znak�w do wypisania. No i w ARMach adres
to adres - mo�e sobie by� w obszarze programu (np. w pami�ci Flash),
mo�e by� w danych. A w AVRach to dopiero jest jazda - wymagane s�
oddzielne funkcje pobieraj�ce ten ci�g z pami�ci danych (printf) oraz z
pami�ci programu (printf_P) i specjalne makra nakazuj�ce umieszczenie
ci�gu znak�w w pami�ci programu.
--
Adam Dybkowski
http://dybkowski.net/
Uwaga: przed wys�aniem do mnie maila usu� cyfry z adresu.
Adam Dybkowski
> 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.
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).
J.F.
>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
Otoz to. Tez zle.
J.
T.M.F.
> pierwszy parametr adres ci�gu znak�w do wypisania. No i w ARMach adres
> to adres - mo�e sobie by� w obszarze programu (np. w pami�ci Flash),
> mo�e by� w danych. A w AVRach to dopiero jest jazda - wymagane s�
> oddzielne funkcje pobieraj�ce ten ci�g z pami�ci danych (printf) oraz z
> pami�ci programu (printf_P) i specjalne makra nakazuj�ce umieszczenie
> ci�gu znak�w w pami�ci programu.
Wiele tych niedogownosci jest gcc-specyficznych, bo gcc nie obsluguje
segmentow pamieci - ale ma sie to wkrotce zmienic. Ale ma to tez zalety
- w AVR mozesz miec 64kB FLASH i 64kB SRAM i ciagle adresowac je za
pomoca 16-bitowych wskaznikow, co daje istotne zyski, a przy madrze
napisanym programie korzystanie z oddzielnych funkcji nie jest az tak
uciazliwe. Inaczej musialbys miec wskazniki co najmniej 17 bitowe, czyli
w praktyce 24 bitowe, niezly overkill dla procesora, ktory wlasciwie nie
ma instrukcji operujacych nawet na 16 bitach.
Funkcje tez mozna napisac uniwersalne - ja np. w jednym z programow
zdefiniowalem sobie makra, ktore powoduja, ze najstarszy bit adresu
interpretowany jest jako wskaznik rodzaju pamieci - jak jest 1 to FLASH,
0 - SRAM, oczywiscie zaweza mi to ilosc obslugiwanej pamieci do 2x32kB,
ale mi to wystarczylo. W C++ mozna to zrobic jeszcze bardziej elegancko
i transparentnie dla programu.
J.F.
>> Druga sprawa to dost�p do danych - np. w funkcji printf podajesz jako
>> pierwszy parametr adres ci�gu znak�w do wypisania. No i w ARMach adres
>> to adres - mo�e sobie by� w obszarze programu (np. w pami�ci Flash),
>> mo�e by� w danych. A w AVRach to dopiero jest jazda - wymagane s�
>> oddzielne funkcje pobieraj�ce ten ci�g z pami�ci danych (printf) oraz z
>> pami�ci programu (printf_P)
>Wiele tych niedogownosci jest gcc-specyficznych, bo gcc nie obsluguje
>segmentow pamieci - ale ma sie to wkrotce zmienic.
Ale jak to sobie wyobrazasz ?
>Inaczej musialbys miec wskazniki co najmniej 17 bitowe, czyli
>w praktyce 24 bitowe, niezly overkill dla procesora, ktory wlasciwie nie
>ma instrukcji operujacych nawet na 16 bitach.
No wlasnie.
J.
slawek7
Jeszcze mam jedną sprawę tak trochę tylko związaną z tematem.
Mówi się ze dane z pamięci Flash są pobierane wolniej niż z RAM. czy
jest to gdzieć napisane. Przykład. Spotkałem opis programu na ARM typu
AT91SAM7S256 w którym w celu przyspieszenia pracy zrobiono "sztuczkę"
polegającą na przerzuceniu programu z FLASHa do RAM.
Dlaczego.Przecież to odczyt. Rozumiem zapis do pamięci, ale odczyt
miałby być dłuższy?
Skąd to się bierze?
J.F.
>M�wi si� ze dane z pami�ci Flash s� pobierane wolniej ni� z RAM. czy
>jest to gdzie� napisane. Przyk�ad. Spotka�em opis programu na ARM typu
>AT91SAM7S256 w kt�rym w celu przyspieszenia pracy zrobiono "sztuczk�"
>polegaj�c� na przerzuceniu programu z FLASHa do RAM.
>Dlaczego.Przecie� to odczyt. Rozumiem zapis do pami�ci, ale odczyt
>mia�by by� d�u�szy? Sk�d to si� bierze?
Z osiaganych czasow dostepu w technologii SRAM i FLASH ?
Bo tak jak siegam pamiecia to SRAM byly szybsze, choc to czasem trudno
porownac.
J.
Paweł
> M�wi si� ze dane z pami�ci Flash s� pobierane wolniej ni� z RAM. czy
> jest to gdzie� napisane. Przyk�ad. Spotka�em opis programu na ARM typu
> AT91SAM7S256 w kt�rym w celu przyspieszenia pracy zrobiono "sztuczk�"
> polegaj�c� na przerzuceniu programu z FLASHa do RAM.
> Dlaczego.Przecie� to odczyt. Rozumiem zapis do pami�ci, ale odczyt
> mia�by by� d�u�szy?
> Sk�d to si� bierze?
Wszystko jest dok�adnie opisane w dokumentacji do procesora.
W zale�no�ci od cz�stotliwo�ci zegara programuje si� odpowiednie
op�nienia przy dost�pie do pami�ci Flash. Tak wi�c w praktyce
wykonywanie programu w pami�ci RAM zwykle jest znacznie szybsze.
Paweďż˝
Adam Dybkowski
100% true. A do tego je�eli ju� m�wimy o AT91SAM7Sxx to tam wewn�trz
jest AFAIR pami�� Flash o organizacji 16-bitowej i dlatego wykonywanie
programu w trybie ARM (o instrukcjach 32-bitowych) jest powoolne.
Dodatkowo pami�� Flash ma 1 waitstate powy�ej chyba 33 MHz zegara (a ten
procek musi �miga� na 48MHz gdy dzia�a USB). Pobrania z pami�ci programu
s� "pakowane" w kawa�ki 32-bitowe (taki mini cache). Ale i tak w
praktyce warto kompilowaďż˝ wszystko w trybie Thumb (z instrukcjami
16-bitowe) - nie do��, �e kod jest kr�tszy to jeszcze szybciej dzia�a
niďż˝ w trybie Thumb. A krytyczne czasowo funkcje kompilowaďż˝ w trybie ARM
i wykonywaďż˝ z RAMu.
Jak mi�o, �e nie trzeba takich kombinacji alpejskich robi� w ARM9 (np.
AT91SAM9260), bo pami�� cache programu �miga z pe�n� pr�dko�ci� (a dane
pobiera np. z SDRAM ca�ymi liniami do cache). W tym przypadku kompilacja
w trybie Thumb daje co prawda kr�tszy kod wynikowy, ale wolniejszy.