IAR si dsPIC

[Vizitator florin_o]

Salut !Am incercat sa compilez urmatoarea secventa pe un compilator IAR pentru dsPIC (1.20B/W32 - Evaluation version ). #include signed short i , j , k ;int main( void ){ k = add(i,j); //adunare cu saturarea rezultatului return 1;}Mesajul de eroare este urmatorul :Internal Error: [CoreUtil/General]: 1: bad byte count for graph (16 vs. 12)Nu prea imi dau seama ce se intampla.Poate ma ajutati voi.Multumesc anticipat...

[bogdanm]

Aparent tocmai ai gasit o eroare interna in compilator. Solutii posibile:- le scrii baietilor de la IAR si astepti sa rezolve problema. Solutia merge perfect daca durata medie de viata este undeva in jur de 1492 ani, altfel nu prea ai sanse sa se rezolve la timp decat daca esti incredibil de norocos.- rescrii codul in ASM- te joci un pic cu el. De exemplu schimbi tipul datelor, fortezi conversii explicite, nebunii din astea.Oricum ar fi, vei avea nevoie de bafta ;)

[Cristiano]

Dupa mesajul ala de eroare pare a fi o eroare interna a compilatorului. Pentru verificare ai putea incerca sa compilezi acelasi cod cu MPLAB C30 (compilatorul de C de la Microchip, au demo valabil 60 de zile), ori, dupa cum a zis si bogdanm, sa incerci sa schimbi cate ceva prin cod.

[Vizitator florin_o]

Din pacate nu prea am ce sa modific. Functia prezentata este declarata si definita de ei ( este declarata in fisierul gsm.h ).Am vrut sa folosesc compilatorul lor deoarece pe langa aceasta functie se mai gaseau inca vreo 20 ( multiplicari , scaderi , adunari pe 16 si 32 de biti cu saturarea rezultatului ).Ma gandesc sa nu aibe legatura cu varianta de evaluare.Oricum m-am reintors la compilatorul celor de la Microchip,o sa mai pierd 2 zile cu rescrierea functiilor ... dar asta e.

[MirceaM]

k = add(i,j); //adunare cu saturarea rezultatului Este corect ce s-a spus. Cand ai o eroare fie investighezi, afli si corectezi fie... ocolesti problema rescriind secventa in cauza. Daca as sti (daca ar explica cineva) ce se intelege prin "adunare cu saturarea rezultatului" (sau daca am vedea sursa functiei add) este posibil sa pot sa comentez cate ceva despre cauza erorii.

[cirip]

Adunarea cu saturarea rezultatului este un fel de sumator cu limitator. Suma saturata nu va depasi o anumita valoare, chiar daca suma algebrica traditionala a termenilor insumarii ar depasi valoarea respectiva.Exemplu: Sa presupunem ca dorim sa efectuam o suma saturata cu valoarea de saturatie de 12.6+5 (saturat)=117+5 (saturat)=127+7 (saturat)=12, desi suma algebrica ar fi 14Suma saturata este o operatie frecvent intalnita in desepeala. Scopul ei este, de obicei, prevenirea depasirii capacitatii de reprezentare a valorilor ca urmare a operatiei cu numere prea mari. De ex, daca se lucreaza pe 16 biti, domeniul maxim care se poate reprezenta este -32768...+32767. In urma unei sume algebrice de genul 30000+5000, rezultatul pe 16 biti ar fi eronat. Daca se satureaza la 32000 atunci rezultatul arata ca un amplificator impins la blana, ceea ce este mai tolerabil decat sa se produca o schimbare de semn (datorita depasirii capacitatii).Cirip

[MirceaM]

Da, multumesc Cirip. Imi dau seama ca exista o legatura cu anumite chestiuni stricte de electronica, cu amplificarea si limitarea.

 

Nu vreau sa ma hazardez in a lansa "ipoteze", as mai astepta, daca se va putea sa vedem si sursa acelei functii de adunare cu saturatie.

 

Doar asa, ca supozitie, cred ca este posibil sa existe ceva incurcaturi la tratarea variabilelor cu/fara semn, chiar daca este vorba de oameni bine pregatiti, de creatori de compilatoare.

 

Asa ca, in asteptarea acelei surse, adaug urmatoarele.

 

1.

Un zvon, mai mult sau mai putin, poate stie cineva detalii. Se spune ca o racheta frantuzeasca s-a prabusit pentru motivul ca un program C a trebuit portat de pe un sistem pe altul, de la un compilator la altul iar programatorul in cauza nu a sesizat sau nu acordat suficienta atentie deosebirilor de tratament pentru variabile intregi cu/fara semn.

Deosebiri intre compilatoare exista, cum se va vedea si mai jos.

 

2.

Ceva sigur, asta nu e zvon. In limbajul Java nu exista tipul unsigned!!!

 

3.

Sa consideram programul urmator.

 

#define U08 unsigned int8#define U16 unsigned int16void main(){ U08 v08; U16 v16; set_tris_a(0x0F);   // 00001111 set_tris_b(0xF0);   // 11110000 set_tris_c(0x90);   // 10010000 // LCD_INIT(); //LCD_CLEAR();   v08 = 3; v16 = v08*100; printf(LCD_PUTCH, "%lu  ", v16  )  ; while( 1 ); }

Acest program se porteaza pe PC, cu modificari minore:

unsigned char v08; unsigned int  v16;  //  32 biti la VCPP dar nu conteaza pentru ce discutam v08 = 3; v16 = v08*100; printf( "%d ", v16  )  ;

Ei bine, acest program afiseaza 300 cand este "lucrat" pe PC, cu oricare dintre cateva compilatoare (Borland, VCPP) si afiseaza 44 (deci se lucreaza pe 8 biti) cu CCS PIC C compiler (recent, din 2003!), pe PIC.

 

Discutia abia acum ar putea sa inceapa.

In help-ul lui CCS (scris, probabil, chiar de creatorul compilatorului) este mentionat ca asa trebuie sa fie, respectiv ca este o eroare tipica (!!! ) daca se doreste sa se lucreze pe 16 biti, caz in care este obligatoriu sa se scrie:

 

v16 = (U16)v08 * 100;

pentru ca rezultatul sa fie 300.

 

Nu ne grabim sa ne luam dupa el, mai cantarim argumente pro si contra. Pare normal, nu-i asa, ca 3*100 sa produca 300, ca la matematica (unde nu exista preocupare privind reprezentarea interna) dar sa ne gandim ca in C este corecta si o scriere de forma:

 

5;

sau

v08*100;

 

caz in care, se stie, evaluarea expresiei SE FACE.

 

Ce rost are o asemenea "instructiune" in urma careia rezultatul expresiei NU este preluat de catre program, in nici o variabila? Sa spunem ca este vorba de a trece un anumit timp, controlat. Sau ne putem gandi ca in expresie se pot afla si apeluri de functii iar in corpul acestora se poate afla orice instructiune, se poate executa orice. De fapt nici nu conteaza ce rost (scop) are, important este ca ea exista, la orice compilator de C.

 

Deci nu exista, in acest caz, nici un fel de atribuire. Chestiunea evaluarii expresiei nu are legatura cu instructiunea de atribuire.

Expresia are o existenta de sine statatoare, ea exista in textul sursa al programului sub forma unui string si are o anumita lungime, numarul de caractere ale stringului.

Intre aceste 2 "limite" (primul si ultimul caracter) nu exista nici o entitate (obiect, variabila) de 16 biti si atunci ce motiv exista sa se faca promovare la 16 biti? Nu prea exista. Acesta ar fi un argument in favoarea modului cum procedeaza CCS.

 

Mai putem mentiona punctul de vedere pacificator. Cand lucram pe PC (codul generat va fi executat de un procesor Intel x86 sau AMD), cu un anumit compilator, il utilizam asa cum este ("luam la cunostinta" ca rezultatul este 300) iar cand lucram cu CCS, pentru PIC, facem acelasi lucru si "ne insusim" ca promovarea de tipuri se face altfel si rezultatul va fi 44.

 

Desigur ca este important si ce spune standardul ANSI.

[Cristiano]

...

Nu prea e normal sa dea 44, chiar si pe PIC. Exista ceea ce se cheama "integral promotion", specificat si in standardul ANSI C, care va face ca automat rezultatul acelei inmultiri sa fie reprezentat pe 16 biti si nu pe 8, inainte de a fi asignat variabilei reprezentate pe 16 biti si fara legatura cu aceasta asignare.De exemplu, pe HiTech PICC18 am obtinut ceea ce se vede in imagine (rezultatul inmultirii este 300).

When there is more than one operand to an operator, they typically must be of exactly the same type.The compiler will automatically convert the operands, if necessary, so they have the same type. Theconversion is to a ?larger? type so there is no loss of information. Even if the operands have the sametype, in some situations they are converted to a different type before the operation. This conversion iscalled integral promotion. PICC-18 performs these integral promotions where required. If you are notaware that these changes of type have taken place, the results of some expressions are not what wouldnormally be expected.Integral promotion is the implicit conversion of enumerated types, signed or unsigned varieties ofchar, short int or bitfield types to either signed int or unsigned int. If the result of theconversion can be represented by an signed int, then that is the destination type, otherwise the conversion is to unsigned int.

[MirceaM]

Da, inteleg cu integral promotion. Pe undeva este normal, am incercat doar sa ma pun in situatia creatorului acestui compilator (CCS) si sa-i inteleg "motivatia".

Nici un compilator nu este 100% conform cu standardul ANSI iar ideea principala este, cred, insusirea caracteristicilor (si ciudateniilor) compilatorului cu care lucram la un moment dat pentru dezvoltarea si finalizarea proiectului la care lucram la un moment dat.

Adica, intr-o anumita situatie (cea descrisa), cu un anumit compilator, trebuie sa ne insusim ca 3*100 = 44, in contextul precizat aici.

Am constatat ca manualul lui CCS din July 2005 tot la fel prevede.

Eu m-am lovit de lucrul acesta, constatand ca rezultatul unor expresii nu este cel asteptat pana cand, insistand, am descoperit care este cauza, respectiv am gasit aceasta mentiune in manualul/help-ul lui (by default, long la CCS este de 16 biti, este acelasi lucru cu int16). Dupa care am scris expresiile asa cum le vrea. Mentiunea se vede in a doua imagine, in dreapta jos.