Różnice między mikrokontrolerami

Feb 05, 2016 46 Replies

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

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.

#define na najprostsza konstrukcje "zwyklego C" ?

J.

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.

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

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

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.

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.

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

formatting link

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.

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

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.

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

Nadal #define moze problem rozwiazac.

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

J.

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.

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

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.

przestrzeń

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

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.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required