Język C i architektury von Neumana i Harvard

[Sławek5]

Cześć.

Możecie mi jakoś wytłumaczyć o co chodzi w stwierdzeniu, że język C jest przystosowany do architektury von Neumana.
Na czym to polega.. Przecież to normalne, że w mikrokontrolerach pamięć programu jest oddzielona od danych.
Moje pytanie to nawiązanie do 2 artykułów w EP 3/06 (str. 107) i 4/06 (str. 109).
Na czym ma niby polegać pełne wykorzystanie języka C dla połączonych obszarów pamięci.

[a_antoniak]

Możecie mi jakoś wytłumaczyć o co chodzi w stwierdzeniu, że język C jest przystosowany do architektury von Neumana.

mylisz C z kompilatorem AVR-GCC

Na czym to polega.. Przecież to normalne, że w mikrokontrolerach pamięć programu jest oddzielona od danych.

to nie jest normalne, choc jest tak dosc czesto

Moje pytanie to nawiązanie do 2 artykułów w EP 3/06 (str. 107) i 4/06 (str. 109).
Na czym ma niby polegać pełne wykorzystanie języka C dla połączonych obszarów pamięci.

kompilatora AVR-GCC, nie jezyka C. Polega na tym, ze w przypadku architektury Harvard do odwolywania sie do obszaru pamieci programu uzywa sie innych instrukcji assemblera, a do obszaru danych - innych. W przypadku AVR-GCC, aby odwolac sie do pamieci programu, uzywa sie dodatkowych specjalnych makr. W bardziej "natywnych" kompilatorach, jest to okreslane na podstawie typu danej (specjalnego kwalifikatora).

BTW - nie ma czegos takiego jak architektura Von Neumanna . Jest maszyna Von Neumanna (tzw. uniprocesor Von Neumanna), ale to ne to samo. Architektura niejako przeciwstawna do arch. Harvard jest arch. Princeton.

[Sławek5]

DZięki za odpowiedź.
Ale powiedz dlaczego piszą że język C jest właśiwie "stworzony" do architektury von Neumanna, jeżeli różnica ma polegać na tym jaki klasyfikator pamięci zastosujemy?

[tomek_j]

DZięki za odpowiedź.
Ale powiedz dlaczego piszą że język C jest właśiwie "stworzony" do architektury von Neumanna,.......

A dlatego, ze jest to kolejny przykład na głupote wciskaną przez kogoś tam i powtarzaną przez innych....
Sam jezyk C i jego kompilator zostały juz dośc dawno temu stworzone przez Dennisa Ritchie. Ten Pan napisał kompilator C, system operacyjny UNIX i wiekszość programów użytkowych dla komputera DEC PDP11, bo taki akurat miał pod ręką . Założył, ze jezyk C nie bedzie musiał byc szczegolnie pwiązany z systemem operacyjnym i ze sprzetem i tak jest w rzeczywistości.
Wiem ze moze sie pojawic chór wyznawców teorii, ze ten czy ów procesor ma liste rozkazów zorientowaną na jezyk C, a le według mojego skromnego zdania to kazdy procesor ma liste rozkazow zorientowaną na samego siebie .

[a_antoniak]

Wiem ze moze sie pojawic chór wyznawców teorii, ze ten czy ów procesor ma liste rozkazów zorientowaną na jezyk C, a le według mojego skromnego zdania to kazdy procesor ma liste rozkazow zorientowaną na samego siebie .

Przeciez nie o to chodzilo w pytaniu.

[tomek_j]

Przeciez nie o to chodzilo w pytaniu.

A o co chodziło - w pytaniu oczywiście ?

[Sławek5]

Spróbuje inaczej.
Jeżeli pamięci są rozrzielone jak np AVR czy 8051 to dostęp do odpowiedniego typu pamięci jak ma się odbywać.
Chyba zwyczajnie jak każda inna zmienna jest traktowana -tak czy nie.

Więc dla mnie zbytnoi nie ma różnicy.

Nie rozumiem tylko tych makr w AVR-GCC PSTR("znaki");

[tasza]

hmm, na mój biedny rozum...popatrz tak:

Kod: Zaznacz cały

char jakas_zmienna; char *pWskaźnik_na_zmienna = &jakas_zmienna;

powiedzmy że typowy von Neumann - czyli CPU pt. Z80 i powiedzmy że typowy Harvard - 8051...
dla pierwszego przypadku kod jest jednoznaczny - zmienna siedzi __gdzieś__ w pamięci,
adresacja jest liniowo od 0 do FFFF, część z tego obszaru to z reguły ROM, reszta to RAM to nie jest teraz istotne.
Ważne, że nie jest wymagane specjelne pokazywanie palcem kompilatorowi gdzie dany obiekt umieścić.
On będzie gdzieś pomiędzy 0...a FFFF, tak?
A w takiej '51 już jest inaczej - w uproszczeniu - typów pamięci jest trzy: wewnętrzna pamięć danych,
zewnętrzna pamięć danych no i pamięć programu.
Można sobie wyobrazić sytuację, że 'jakas_zmienna' bedzie przykładowo w zewnętrznej pamięci danych (XDATA)
pod adresem a niech tam: 0xAAAA, a może też być (ale w roli np. stałej, niemodyfikowalnej wartości) w CODE,
pod tym samym bezwzględnym, liczonym od zera adresem.
I wtedy już trzeba powiedzieć kompilatorowi do której pamięci ma sięgnąć, a robi się to specjalnymi słowami kluczowymi,
czy innymi zaklęciami - zależnie jakie podejście zastosowali autorzy danego kompilatora.
Nie jest to specjalne utrudnienie, gdy rozumie się architekturę danego procesora, niemniej jednak składniowo jest to
odstępstwo od 'klasyki' - która powstała na, jak to tomek_j napisał, nieharvardowej architekturze...uff.

PSTR("znaki") nakaże kompilatorowi umieścić "znaki" we flash, w pamięci kodu.
aby z danych (stałych, napisów) we flash skorzystać masz zestaw specjalnych funkcji, z sufikesm _P (są w pgmspace.h).
I to jest właśnie to (nie)przystosowanie...poniważ chcesz trzymać we pamięci kodu
nie tylko kod maszynowy, ale i dane - musisz 'czarować'.
Choć ciągle robisz to w języku C....

[tomek_j]

Spróbuje inaczej.
Jeżeli pamięci są rozrzielone jak np AVR czy 8051 to dostęp do odpowiedniego typu pamięci jak ma się odbywać.
Chyba zwyczajnie jak każda inna zmienna jest traktowana -tak czy nie.

Więc dla mnie zbytnoi nie ma różnicy.

Nie rozumiem tylko tych makr w AVR-GCC PSTR("znaki");

W kompilatorach C dla mikrokontrolerów zawyczaj dostęp do pamieci jest okreslony przez deklaracje typu zmiennej. I tak standardowe deklaracje char, int, long itp odnosza sie do zmiennych z pamieci RAM. Jezeli zmienna mam byc umiesczona w pamieci programu dodaje sie niestandardowe rozszerzenie np const char tab[200], rom const char tab [200], lub jakoś tam inaczej - patrz manual do kompilatora. Kompilator wtedy wie jakich instrukcji maszynowych ma wtedy użyc, żeby miec dostep do odpowiedniej danej.

[a_antoniak]

...do zmiennych z pamieci RAM. Jezeli zmienna mam byc umiesczona w pamieci programu ...

Dodam tylko, ze pamiec programu tez moze byc pamiecia RAM (niekoniecznie Flash) . Chodzi nie o typ pamieci, ale o sposob dostepu do niej (jej "umieszczenie" w systemie). Poza tym, mysle, ze juz wszystko dokladnie wyjasnilismy Slawkowi .

[tomek_j]

Dodam tylko, ze pamiec programu tez moze byc pamiecia RAM (niekoniecznie Flash) .

W dorosłych komputerach program jest ładowany z innego nośnika HDD, CD w nowych rozwiazaniach lub np z czytnika tasmy papierowej lub kart perforowanych w muzelanych rozwiazaniach do pamieci RAM i po załadowaniu wykonywany. Dlatego deklaracje zmiennych i dostep do nich sa spójne i nie sprawiaja programiscie problemu. Np. deklaracja char oznacza zmienna 8 bitowa w pamieci komputera i tyle
No tak, ale rozwazamy mikrokontrolery i programowanie w C. W znanych mi mikrokontrolerach 8 bitowych program jest zapisany w pamieci typu ROM (Flash, EEprom, ROM) i raczej nie jest ładowany do RAMu. Z tego powodu jest potrzebne rozoróżnienie czy zmienna bedzie umiesczana w ROM w trakcie programowania uC i mozna ja bedzie tylko odczytac, czy tez moze jest w pamieci RAM i mozna z nia robic co sie chce. To jest mikrokontrolerowy folklor i producenci kompilatorów dostosowują sie do niego, a nie na odwrót.

[a_antoniak]

Ponownie zauwazam, ze rodzaj pamieci nie determinuje jej roli (pamiec danych/programu). Jak sie w 8051 podepnie 62256 pod PSEN, to pamiec RAM pelni role pamieci programu. Nie ma tu mowy o zadnym "ladowaniu programu z Flash do RAMu".

[Jurek Szczesiul]

DZięki za odpowiedź.
Ale powiedz dlaczego piszą że język C jest właśiwie "stworzony" do architektury von Neumanna,.......

A dlatego, ze jest to kolejny przykład na głupote wciskaną przez kogoś tam i powtarzaną przez innych....
Sam jezyk C i jego kompilator zostały juz dośc dawno temu stworzone przez Dennisa Ritchie. Ten Pan napisał kompilator C, system operacyjny UNIX i wiekszość programów użytkowych dla komputera DEC PDP11, bo taki akurat miał pod ręką .

Ale się rozpętało, lufy się grzeją

Ja nigdzie nie twierdziłem, że C jest jakoś automagicznie i urzędowo podporządkowany
von Neumannowi. Ale faktem jest , że właśnie w takim środowisku powstawał. I gdy trafia
pod Harvard - jego standardowe mechanizmy nie wystarczają i konieczne są różnego
rodzaju rozszerzenia i tricki. Pojawiają się dodatkowe klasyfikatory obszaru pamięci,
rozszerzone wskaźniki itd. , których pierwotny PC-towy C nigdy nie znał bo nie
potrzebował. Różne kompilatory dedykowane konkretnym uK radzą sobie z takim
rozszerzaniem bardziej lub mniej zgrabnie - avr-gcc wypada dosyć średnio.
I po to były te wszystkie wywody - aby nie dziwić się , czemu pod avr-gcc nie
chce działać zgodnie z oczekiwaniami jak najbardziej poprawny składniowo i zgodny ze standardami kod typu np.
const a=10;
b=a;
a w zamian występuje szereg rozmaitych kombinacji z atrybutami , makrami itd.

Jednak chyba mi to wyjaśnianie nie do końca wyszło

Pozdrawiam Wszystkich !!
Jurek S.

[bis]

Piękny temat! Ale warto sięgnąć do korzeni. jezyk C juz praktycznie nie występuje w swojej pierwotnej postaci, zastąpiły go konkretne implementacje proponowane przez twórców kompilatorów oraz organizacje standaryzujące.
W architekturze von Neumana nie ma rożnicy pomiędzy przestrzenią danych i programu, jest to ta sama przestrzeń. te same instrukcje i adresowanie powodują że wyłącznie od przebiegu programu zależy czy aktualnie pobierany z pamięci ciąg bitów (bajt, słowo, itd) jest kodem instrukcji czy jakąś przetwarzaną daną, a nawet w pewnych sytuacjach raz może to być dana a raz program (np. można napisać program który się sam skasuje). Ważną cechą C jest organizacja stosu i przekazywanie parametrów do funkcji, właśnie w architekturze von Neumana można łatwo robić funkcje o zmiennej liczbie parametrów (np. printf!!!) Inną konsekwencją jest to że można potraktować wskażnik do danych jako wskażnik do funkcji i tę funkcję wykonać (cwane sposoby dynamicznego modyfikowania kodu) Różnego rodzaju kwalifikatory pojawiły się wraz z koniecznością wspomagania programistów w automatycznym wykrywaniu potencjalnych żródeł blędów( standardy ANSI). Oraz inplementacjami C na architektury Harvard gdzie pojawiają się różne przestrzenie pamięci (rozłączne z powodu innych mechanizmów dostępu do nich) I tu już nie można traktowac wskażników dowolnie, kopiować czy wykonywać na nich operacji, nie można porównywać ze sobą a rzutowania wskażników z jednej przstrzeni na inną z reguły kończą się katastrofą. A organizacja stosu jest dużo bardziej skomplikowana (raczej są to stosy, osobno związane z organizacją programu i osobno z danymi) A implementacja long_jump() to już horror.
A teraz trochę poprawek: Tomku_i - popełniasz najbardziej typowy błąd przypisywania typowi jego znaczenia wyrażonego w bitach, typ char to nie zawsze jest 8 bitów!! w książce "Język C" p. Kernighana i Ritche'go jest taka tabelka dotycząca typu "char" np. na Honeywell 6000 jest to 9 bitów. Dużo lepiej jest to widoczne w typie "int" który bywa 16 bitowy albo 32 bitowy. Rozmiary allokacji są specyficzną sprawą kompilatora i mikroprocesora na który jest on implementowany. Generalnie ma to ograomne znaczenie gdy chcesz po latach skożystać opracownych i przetestownych przez siebie funkcji na jakimś nowym procku.
O tym czy zawartość danej przestrzeni jest programem czy nie decyduje wyłącznie sposób w jaki procesor wykorzystuje to co z niej odczytuje, nie ma znaczenia czy będzie to FLASH, RAM czy EPROM.

pozdrowienia

[Piotr]

Jednak chyba mi to wyjaśnianie nie do końca wyszło :-(

Pozdrawiam Wszystkich !!
Jurek S

******************************
Czyli zrobimy upgrade artykulu? Wyraznie trzeba pare rzeczy dopowiedziec ;-)
Pzdr
PZb

[Sławek5]

Jeszcze raz dziękuję za cenne uwagi.
Bardzo dobrze, że istniejecie i pomogliście mi to troszkę "okiełznać".

[tomek_j]

A teraz trochę poprawek: Tomku_i - popełniasz najbardziej typowy błąd przypisywania typowi jego znaczenia wyrażonego w bitach, typ char to nie zawsze jest 8 bitów!! w książce "Język C" p. Kernighana i Ritche'go jest taka tabelka dotycząca typu "char" np. na Honeywell 6000 jest to 9 bitów.
Dużo lepiej jest to widoczne w typie "int" który bywa 16 bitowy albo 32 bitowy. Rozmiary allokacji są specyficzną sprawą kompilatora i mikroprocesora na który jest on implementowany.

Taa.... ale ja tą dyskusje rozumiałem jako dyskusje w kontekście programowania mikrokontrolerów 8 bitowych w języku C, a nie rozważania ogólne. 9 bitowy char jest dzisiaj tak samo łatwo znależć jak prawdomównego polityka .
W 8 bitowcach int jest prawie zawsze 16 bitowy, ale i tak zawsze to trzeba sprawdzić. Zreszta twórcy języka C wyraźnie to zaznaczają - długośc słowa może mieć dla danego typu różną długość.

Generalnie ma to ograomne znaczenie gdy chcesz po latach skożystać opracownych i przetestownych przez siebie funkcji na jakimś nowym procku.
O tym czy zawartość danej przestrzeni jest programem czy nie decyduje wyłącznie sposób w jaki procesor wykorzystuje to co z niej odczytuje, nie ma znaczenia czy będzie to FLASH, RAM czy EPROM.
pozdrowienia

tez racja, ale w trakcie pisania programu trzeba popdpowiedzieć kompilatorowi: to jest program, to jest zmienna, która mozna odczytywać i zapisywać i musi byc umiesczona w pamięci RAM użytkownika, to jest tablica w pamięci ROM itp. Jeszcze raz powtarzam i jeżeli sie myle to prosze mnie wyprowadzic z błedu: programista pisząc program w C dla mikrokontrolerów musi wiedziec jakie on ma zasoby i odpowiednio deklarowac przestrzenie pamięci.
Twoja teze w tym przypadku jaj bym postawił odwrotnie - o tym w jaki sposób procesor wykorzystuje zawartośc pamięci decyduje jeje rodzaj - umieścisz tablicę do zapisu/odczytu w obszarze pamięci Flash ikrokontrolera? - oczywiście że nie. Oczywście mozesz powiedziec, ze w twoim rozwiazaniu jak sugeruje Arek pamiecia programu jest pamięc RAM i mozna. Ale pamiecia programu w praktycznych rozwiązaniach jest ROM

Ponownie zauwazam, ze rodzaj pamieci nie determinuje jej roli (pamiec danych/programu). Jak sie w 8051 podepnie 62256 pod PSEN, to pamiec RAM pelni role pamieci programu. Nie ma tu mowy o zadnym "ladowaniu programu z Flash do RAMu".

Nie sugerowałem, że program musi być zapisany w pamieci ROM, ale że jest prawie zawsze tam zapisany. Oczywiście mozna zrobic tak jak napisałeś, ale czy któs tak robi? Chciałem zwrócic uwage na codzienna praktykę, czyli rozwiazenia stosowane prawie zawsze, a nie na teoretyczne (bezsensowne? ) możliwości.

[a_antoniak]

Chciałem zwrócic uwage na codzienna praktykę, czyli rozwiazenia stosowane prawie zawsze, a nie na teoretyczne (bezsensowne? ) możliwości.

A debuggowanie kodu ARM7 (i nie tylko) z RAM traktowanej jako pamiec programu tez jest bez sensu? Wrzuc na luz i mniej jaduuuu. Napisales (dwukrotnie), cos co wyraznie nie jest prawda choc i tak wiadomo o co chodzi. Byl to raczej "skrot myslowy" niz jakas wielka herezja, ale poczatkujacym moglo namieszac w glowach. Dlatego bis i ja rzucilismy uwagi porzadkowe (sluszne zreszta), ktore w zadnym razie nie podwazaly Twojego profesjonalizmu i mysle, ze kazdy pozytywnie nastawiony czlowiek odpisalby tylko "ok, racja". Nie rozumiem po co sie licytowac, tym bardziej ze zaleznie od implementacji program moze byc pobierany z pamieci RAM i kropka.

[bis]

Tomku_i: Zgadzam się całkowicie że trzeba znać i rozumieć procesor na który pisze sie oprogramowanie
Chyba jednak się nie możemy zrozumieć z powodu używania tych samych słów w ich odmiennych znaczeniach. Odnoszę wrażenie że "program" to dla ciebie wszystko co jest zapisane w jakimś nieulotnym nośniku typu ROM ( ale gdybyś zastosował FRAM to już twój przykład nie jest bezsensowny)
Dyskusja chyba jednak dotyczyła architektur i ich wpływu na na kodowanie w C. W tym kontekście słowo "program" jest ciągiem bitów wpływającym na stan skomplikowanego automatu jakim jest procesor, prościej mówiąc jest to rozkaz. jakie będzie jego zródlo jest tu obojętne.Wszystko zależy od tego jak jest zbudowana reszta. Ale jak trafisz na procesory do których będziesz musiał napisać bootloader (bo ISP procka potrafi jedynie zapisać 128 bajtów z UARTU do RAM i tam skoczyć) to może stanie się to bardziej zrozumiałe. A jeszcze inny przykład: w systemach opartych na Z80 w trakcie wykonywania skoku do tablicy przerwań część "rozkazu" (adresu skoku) dla procesora jest pobierana nie z pamięci ale bezpośrednio z układu generującego przerwanie.
Jeszcze coś sobie przypomniałem: W procesorach DSP, z powodu różnicy w czasach dostępu krytyczne fragmenty kodu prawie zawsze są wykonywane z wewnętrznego RAM do którego w miare potrzeby przrzuca się odpowiednie procedury z innego podsystemu obsługi pamięci (np. FLASH ) ale adresowanie jest w tej samej przestrzeni tylko w innych obszarach adresowych.
[/quote]

[a_antoniak]

Ale jak trafisz na procesory do których będziesz musiał napisać bootloader (bo ISP procka potrafi jedynie zapisać 128 bajtów z UARTU do RAM i tam skoczyć)

a niektore nawet mniej (typu 32 bajty) . Mysle, ze Tomek powie, ze bootloaderow i tak sie nie pisze, bo wszystkie zostaly juz napisane .

A jeszcze inny przykład: w systemach opartych na Z80 w trakcie wykonywania skoku do tablicy przerwań część "rozkazu" (adresu skoku) dla procesora jest pobierana nie z pamięci ale bezpośrednio z układu generującego przerwanie.

Mysle, ze Tomek powie, ze to bylo dawno i nieprawda. Moze bedzie mial racje, ale jednak...