Różnice między mikrokontrolerami

Ponieważ o ile pamietam dla gcc pointer jest tylko "wartością" i nie zawiera innych znaczeń. To ogranieczenie pochodzi z faktu że developing gcc odbywał się na w miarę normalnych architekturach gdzie nie był to kłopot i tak zostało.

Problem tak naprawde nie jest w gcc tylko w C/C++ (np wskaźnik na funkcje nie jest kompatybilny z void* [1] co jest zrobione m.in. z powodu jakiś dziwacznych architektur).

Nie wie. Byly próby aby się dowiedział w postaci propozycji zmiany. Zdaje się że nie udało się wpuscić tego do mainstream, spodziewam się że takie ficzery trafią wcześniej do clang. Nie mogę teraz znaleźć pdfa który tą zmianę prezentował, jak znajdę to go tu wrzucę.

[1]
formatting link
Reply to
Sebastian Biały
Loading thread data ...

Dnia Sat, 6 Feb 2016 00:08:06 +0100, Grzegorz Kurczyk napisał(a):

Przy czym zauwaz, ze to jest luzno zwiazane z "harvardowoscia".

Osobna pamiec programu ... program w C w zasadzie programu nie rusza, a tam gdzie rusza (adres funkcji), tam kontekst jest z gory ustalony.

Problemem sa dane przechowywane w pamieci programu. Cos w zasadzie sprzeczne z harwardowoscia :-)

C sie z tym boryka od dawna - byl chocby segment danych niezainicjowanych i zainicjowanych czy nawet stalych.

Oczywiscie w uC przez dlugi czas bylo malo pamieci, co zachecalo do uzycia ROM, z drugiej strony ROM jest wolny, a RAM szybki, co zacheca do przepisania programu do RAM. Nawet jesli to specjalny RAM, wydzielony tylko na program :-)

Harvard Harvardem, ale w co bardziej uniwersalnych systemach jest potrzeba aby program tworzyl program do wykonania w RAM, czy nawet zaczytywal go z dysku. I dostep do pamieci programu musi byc, nawet jesli to pamiec specjalna.

J.

Reply to
J.F.

#define na najprostsza konstrukcje "zwyklego C" ?

J.

Reply to
J.F.

Dnia Sun, 07 Feb 2016 02:20:45 +0100, Marek napisał(a):

No przeciez wiesz - zeby program w C wiedzial, gdzie czytac

No w zasadzie tak. Moze to poklosie wczesniejszych czasow, gdy kompilator byl glupszy ? A moze jednak ma zalety, takie bezposrednie podkreslenie, ze tu jest cos inaczej, a nie - zdefiniowane trzy strony wczesniej.

J.

Reply to
J.F.

Pytanie co zrobisz gdy portujesz harvard->harvard i obie implementacje radośnie wymysliły własny lepszy sposób na grzebanie w rom.

Reply to
Sebastian Biały

W dniu 2016-02-07 o 02:20, Marek pisze:

No ale Ci tłumaczą wszyscy że w avr-ach nie czyta, musi czytać przez pgr_read_xxx(tab[index]), to jest konsekwencja innego dostępu do pam programu która pokrywa się adresami z pamięcią ram.

Nie, nie wie, to ty mu okreslasz skąd ma czytać.

Reply to
janusz_k

W dniu 2016-02-07 o 08:28, slawek pisze:

To kompilator ma a nie procek, x86 od zawsze miały wspólną przestrzeń danych i programu. Te segmenty są na siłę robione i to dopiero ostatnimi czasy jak się pojawiły wirusy korzystające z przepełnienia stosu.

Łaskawco rozrózniaj instrukcje dostępu do pamięci "mov" od instrukcji we/wy "in", bo jak na razie to mieszasz pojęcia.

Reply to
janusz_k

Pisałem ogólnie o kompilatorach, np. sdcc umie, stąd nie widziałem, że gcc-avr ma z tym problem, ale już Sebastian wyłuszczył dlaczego.

Reply to
Marek

GCC jakiś czas temu nauczyło się rozróżniać przestrzenie adresowe:

formatting link

Reply to
Zbych

To nie wystarczy. Np. w przypadku AVR każda funkcja przyjmująca wskaźnik musiala by się generować osobno dla każdej kombinacji typów wskaźnikowych jakie w programie wystąpią. Dlatego nalezy użyć __flash przy wskaźnikowym argumencie funkcji, czyli znowu wychodzi na to że bez rękodzieła ani rusz.

Reply to
Sebastian Biały

To jest raczej oczywiste, tyle że nie trzeba ręcznie wstawiać pgm_read_cośtam.

Reply to
Zbych

A sdcc testowałeś? O ile pamiętam ają port avr. Port pic16 (układy

18F) daje radę z mieszaniem wskaźników ram/flash (nie odróżnia os strony programisty), więc może i port avr podobnie.
Reply to
Marek

A obsługuje C++? Bo jak nie to jest *bezużyteczny*.

Reply to
Sebastian Biały

Nadal #define moze problem rozwiazac.

A jesli nie ... no coz, za cos ci programsci musza brac pieniadze :-)

J.

Reply to
J.F.

Dnia Sun, 7 Feb 2016 13:03:39 +0100, janusz_k napisał(a):

Przestrzen wspolna, adresacja jedna, ale i tu moze segmentacja namieszac. Ktos jeszcze pamieta te modele pamieci w C - tiny, small, huge .. 6 ich bylo :-(

od x386 sie troche zmienilo

No, nawet w pelnej adresacji 32 bit te segmenty maja pewien sens - pozwalaja rozszerzyc przestrzen wirtualna, dynamicznie zarzadzac rozmiarem ... i oszczedniej to robic niz w 64 bit :-)

Poniekad ten sam problem, tylko w jeszcze innym miejscu. taki 8080 nie mial np adresacji in/out posredniej czy przez rejestr, tylko wpisany w rozkaz, - co uniemozliwialo zadanie adresu parametrem

- musial byc z gory okreslony.

J.

Reply to
J.F.

Broń Boże :)

Reply to
Marek

W dniu 2016-02-07 o 22:15, J.F. pisze:

Pewnie, pisałem na nie. Co nie zmienia faktu że można było wpisać dowolny adres i pobrać dane czy zapisać z całej pamięci RAM, dopiero w nowych teraz prockach jest blokada na poziomie jądra procka, tylko procesy systemowe w ringu 0 mają całkowity dostęp.

Jarku sprawdz zanim napiszesz, cytuję: "Other Instructions

IN Port Data from Port placed in A register. OUT Port Data from A register placed in Port."

formatting link

Reply to
janusz_k

Dnia Mon, 8 Feb 2016 21:28:14 +0100, janusz_k napisał(a):

W modelu small byl jednak segment kodu, segment danych, a adres/wskaznik tylko 16 bitow liczyl.

No - dane byly w rejestrze A, a adres portu ? W drugim bajcie rozkazu.

Jesli miales w systemie np dwa porty szeregowe (UART), to nie mogles w systemie napisac jednej procedury ich obslugi, do ktorej bys przekazal adres bazowy sterownika portu. Adres byl staly.

Podobnie w C nie mogles napisac funcji, ktora by dostala adres portu jako parametr. Musial byc staly i znany juz w czasie kompilacji.

Tzn mogles - jesli program byl w RAM a nie ROM, to program mogl sobie zmienic bajt pamieci odpowiedniego rozkazu.

Cos mi chodzi po glowie, ze podobna zmiana kodu musiala byc stosowana takze w x86, ale to jeszcze jakis inny rozkaz musial byc, bo IN/OUT mialy mozliwosc adresowania DX. A jak uwzglednic kolejki i cache, to sprawa przestaje byc prosta :-)

J.

Reply to
J.F.

przestrzeń

Ciekawe. Rejestry DS i CS to w x86 pojawiły się jakieś 30 lat temu...

Reply to
slawek

przestrzeń

Ale pamiec i przestrzen byla jedna. Jak sie do DS i CS wpisalo to samo, to mozna bylo kod traktowac jak dane.

Zreszta wskaznik zawieral i segment, wiec mozna bylo jednolicie adresowac, chyba, ze ktos sie uparl przy modelu small ...

J.

Reply to
J.F.

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.