Dziwne zachowanie kompilatora w AVRGCC.

Sat, 08 May 2004 20:28:16 +0200, na pl.misc.elektronika, Milosz Skowyra napisał(a):

O, teraz wlasnie jest poruszone sedno sprawy. Wlasnie tak jest, bo gcc pochodzi ze swiata ciaglej pamieci, gdzie nie ma pod takimi samymi adresami ramu, flasha i eepromu. Wskaznik jest 2-bajtowy i nie ma w nim miejsca na okreslenie, o ktora pamiec chodzi ( np. w prostym kompilatorku dla 51 mialem wskazniki 3-bajtowe - i tam wszystkie odwolania przebiegaly tradycyjnie - 3. bajt jednoznacznie okreslal typ pamieci ). Wiec zrobiono za pomoca makr i funkcji. Chociaz ostatnio coraz czesciej na liscie avr-gcc pojawiaja sie rozwazania, ze chyba wypadaloby cos z tym w koncu zrobic :-)

Ale w tym przypadku mamy konkretna tablice, w ktorejs jakos sie znalazlo miejsce na atrybut "progmem". Printf czy inna funkcja mialby problemy z okresleniem o ktora pamiec chodzi po wskazniku - ale tablica[i] kompilator moglby prawidlowo skompilowac, bo wie gdzie sie ta tablica miesci.

tak ... zmienic procka :-) Bo ten zawsze bedzie sprawial takie klopoty.

J.

Mozna by to obejsc gdyby narzucic dodatkowy warunek na zgodnosc typow - atrybut wskaznika jest integralna czescia typu i wskazniki na rozne typu pamieci sa niekompatybilne. Wtedy w naglowku funkcji moznaby okreslic jakiego wskaznika oczekuje.

To jest zdaje tzw architektura Harward (nie chce mi sie teraz wyciagac mojej starej pracy dyplomowej o TMS320),

Krzysiek Rudnik

Sun, 09 May 2004 01:31:17 +0200, na pl.misc.elektronika, J.F. napisał(a):

W zasadzie tak - ja zbyt gleboko tego nie znam, tylko temat czesto wraca na grupach avrfreaks i tak mniej wiecej 'wiedzacy' wyjasniaja : rozdzielone obszary sa dla gcc klopotem i zastosowano rozne protezy zeby to obejsc - wyszlo akurat tak jak jest ( wyglada, ze atrybut obszaru jest raczej informacja dla binutilsow avr a sam kompilator skorzystac z tego nie umie )

:-) Wiec raczej moze kompilator, ile to IAR kosztuje ? ;-)

BTW - jakos IMHO nie pasuje roszczenie zbytnich pretensji do narzedzia GNU

- zawsze odpowiadaja, ze jak cos nie tak to ochotnicy mile widziani :-)

Tez wyjscie... a co bys polecal ? Irek promuje H8 Renesansa, ponoc bardzo przyjemne. Jeszcze sie osobiscie nie przygladalem. Pod wzgledem obudowania peryferiami atrakcyjny moze byc Cypres z rdzeniem '51 i FPGA, ale raczej w Polsce malo dostepny. Swoja droga to moze ktos by sprawdzil jak sie ma kompilacja podobnej sytacji w innym srodowisku C, np IAR-a czy CodeVision ??

Jak to sobie konkretnie wyobrazasz? Tj. czym rozni sie

const char* p; wskazujace na dane w RAM od const char* p; wskazujace na dane w ROM?

Mozna oczywiscie dodac do jezyka nowe specyfikatory rodzaju wskazywanej pamieci i zabronic konwersji miedzy nimi, ale to juz nie bedzie C. :-)

Zgadza sie, pamieci danych i programu sa fizycznie rozdzielone.

Pozdrawiam Piotr Wyderski

Pewnego dnia Piotr Wyderski przemówił ludzkim głosem:

^^^^^^^ to bym wywalił

^^^^^^^^ a tu aż się prosi o umieszczenie w romie

Ale czy ktoś się upiera, że to musi być klasyczne C ? To ma być wygodne narzędzie. Jeśli norma nie uwzględnia małego otworu na końcu młotka do powieszenia go na gwoździu, to nie znaczy, że ktoś nie może tego zrobić, a już nie daj boże sprzedawać pod nazwą "ansi/iso młotek" (pod warunkiem, że to rozszerzenie da się wyłączyć).

Nikt sie nie upiera, nawet wprost przeciwnie; ja tylko informuje, ze po takich modyfikacjach to juz nie bedzie C. :-)

Pozdrawiam Piotr Wyderski

Zapomnialem o tym:

A to dlaczego? Co zabrania miec w pamieci RAM dane, ktore w danym kontekscie nie sa zapisywalne (co nie oznacza, ze nie sa zapisywalne w ogole)?

Ale skad kompilator ma o tym wiedziec? OK, jesli const odnosi sie do globalnej definicji danej, to kompilator moze to wywnioskowac, ale co z automatycznymi obiektami z atrybutem const? :-)

Pozdrawiam Piotr Wyderski

Pewnego dnia Piotr Wyderski przemówił ludzkim głosem:

Dla mnie jeśli coś jest stałe to jest stałe i już. (co nie znaczy, że twórcy c myśleli podobnie).

A co to są automatyczne obiekty (w kontekście klasycznego c) ?

Sun, 9 May 2004 13:16:23 +0200, na pl.misc.elektronika, Piotr Wyderski napisał(a):

I tak to jest wlasnie zrobione dla '51 - dodatkowo dla zmiennych (stalych) okresla sie zadany obszar ( np. code, data, idata, xdata ) - potem kompilator juz 'sam wie' jak poszczegolne zmienne obslugiwac.

Sun, 09 May 2004 14:40:01 +0200, na pl.misc.elektronika, Zbych napisał(a):

IMHO oni chyba w ogole nie przewidywali takich problemow - w pecetowym programie i tak de facto wszystko jest w ramie - nie masz stalych, ktore trzeba przy odwolaniu sciagac pojedynczo z dysku ;-)

Pewnego dnia Jurek Szczesiul przemówił ludzkim głosem:

Chwila, przecież c to lata 60 (70 ?) i maszyny unixowe (PDP ?), które już miały ochronę pamięci. Więc jeśli coś jest umieszczone w segmencie kod (a nie danych) to nie powinno się tego dać zmodyfikować z poziomu programu.

Ale w C slowo kluczowe "const" nie znaczy "stale", tylko "nie moze wystapic jako l-wartosc w danym kontekscie" :-) Coz, to nie nasza wina, ze w C slowa kluczowe niezbyt odpowiadaja swoim znaczeniom... Porzadniejsze jezyki maja do tego slowa kluczowe "in" oraz "out", ktore oznaczaja odpowiednio "tylko do odczytu" i "tylko do zapisu", a "const" deklaruje prawdziwe stale, zazwyczaj nie zajmujace ani bajta pamieci (cos jak #define, ale z pelna kontrola typow). Sprawa "const" w C i C++ jest bardzo sliska, szczegolnie po dodaniu atrybutu "mutable", co daje obiekty "czesciowo stale". :->

Obiekty umieszczane przez kompilator na stosie.

Pozdrawiam Piotr Wyderski

A w jaki sposob to konkretnie wyglada? Wprowadzili nowe slowa kluczowe do jezyka, czy tez korzystaja z __attribute__((...))?

Pozdrawiam Piotr Wyderski

Sun, 09 May 2004 15:09:38 +0200, na pl.misc.elektronika, Zbych napisał(a):

Hau ;-)

Fakt - i const wlasnie to okresla. Ale segment tak czy siak w ramie. A tu oddzielny obszar z powielonymi adresami i zupelnie inna maszynowa obsluga dostepu (a stale moga byc przeciez rowniez w eeprom ). Wiec sam const przestaje wystarczac - pozostala z niego tylko funkcja wykrywania bledu przy omylkowej probie zapisu.

Sun, 9 May 2004 16:12:01 +0200, na pl.misc.elektronika, Piotr Wyderski napisał(a):

W tych, ktore ogladalem byly to slowa kluczowe ( zreszta jest to nazwane jednoznacznie, np. w opisach SDCC jako 'mcs51 storage class language extensions' ).

Dodanie __attribute__ juz wykracza poza C.

Krzysiek Rudnik

w '51 to nei wiem, ale w AVR attribute