Zalety i wady architektury Von Neumanna w mikrokontrolerach ARM, np. AT91SAM7256?

Sat Nov 07, 2009 5:54 pm   

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.
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.

Sat Nov 07, 2009 5:54 pm   

On Sat, 7 Nov 2009 07:54:00 -0800 (PST), slawek7 wrote:

Nie musi byc ciagla. Ma byc jednolicie adresowana i dostepna.


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.

Sat Nov 07, 2009 7:30 pm   

On Sat, 7 Nov 2009 10:19:22 -0800 (PST), slawek7 wrote:

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.

Sat Nov 07, 2009 7:40 pm   

J.F. wrote:


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

Sat Nov 07, 2009 8:05 pm   

On Sat, 07 Nov 2009 19:40:08 +0100, Waldemar Krzok wrote:

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.


Tylko pytanie czy z punktu widzenia programu dostep jest inny, czy sa
tylko drobne klopoty, typu 6 modeli pamieciowych C na 8086.


Jesli chodzi o hardware ... to sie ostatnio skomplikowalo i rozmylo.

J.

Sat Nov 07, 2009 8:09 pm   

On 07.11.2009 16:54, slawek7 wrote:

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

Sat Nov 07, 2009 8:19 pm   

No tak ale co mi to daje. Jakie są z tego korzyści? Jakiś przykład, bo
trochę tego nie rozumiem.

Sat Nov 07, 2009 8:39 pm   

slawek7 wrote:

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).


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.

Sat Nov 07, 2009 8:58 pm   

slawek7 wrote:

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ą.

Sat Nov 07, 2009 9:09 pm   

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?

Sat Nov 07, 2009 10:38 pm   

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.

--
Inteligentny dom - http://idom.wizzard.one.pl
http://idom.sourceforge.net/
Teraz takze forum dyskusyjne
Zobacz, wyslij uwagi, dolacz do projektu.

Sat Nov 07, 2009 11:34 pm   

slawek7 pisze:


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.

Sat Nov 07, 2009 11:34 pm   

On Sat, 7 Nov 2009 11:09:49 -0800 (PST), slawek7 wrote:

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.

Sat Nov 07, 2009 11:49 pm   

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).

--
Adam Dybkowski
http://dybkowski.net/

Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.

Sun Nov 08, 2009 12:01 am   

On Sat, 07 Nov 2009 23:49:54 +0100, Adam Dybkowski wrote:

Otoz to. Tez zle.

J.