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.

do góry

On Sat, 7 Nov 2009 07:54:00 -0800 (PST), slawek7 wrote:
>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.

do góry

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


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

do góry

On Sat, 7 Nov 2009 10:19:22 -0800 (PST), slawek7 wrote:
>> Nie musi byc ciagla. Ma byc jednolicie adresowana i dostepna.
>
>No tak ale co mi to daje. Jakie są z tego korzyści? Jakiś przykład, bo
>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.

do góry

J.F. wrote:

> On Sat, 7 Nov 2009 10:19:22 -0800 (PST), slawek7 wrote:
>>> Nie musi byc ciagla. Ma byc jednolicie adresowana i dostepna.
>>
>>No tak ale co mi to daje. Jakie są z tego korzyści? Jakiś przykład, bo
>>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.

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

do góry

On Sat, 07 Nov 2009 19:40:08 +0100, Waldemar Krzok wrote:
>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.

do góry

On 07.11.2009 16:54, slawek7 wrote:
> 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

do góry

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?

do góry

slawek7 wrote:
> Mam do Was prośbę. Wytłumaczcie mi coś.
> Jakie są wady i zalety architektury Von Neumanna w uC ARM np
> 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.

do góry

slawek7 wrote:
> 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ą.

do góry