PASCAL kompajler-moja vecita tema

Mozda se neki secaju da sam nekada davno poceo da pisem PASCAL kompajer.
Imao sam vremena, a onda su dosli poslovi (hvala bogu) obimni, ali i zaradilo se za tih 7-8 godina. Prosle godine se sve polako ugasilo. I eto od nove godine nista ne radim, ali u junu opet krecem u neki veci posao.

Oni koji se secaju znaju da se profesionalno bavim mikrokontrolerima, pisem u asembleru i C-u CodeWarrior. Ali i ja sam hobista, hobi mi je da napisem PASCAL kompajler.

PASCAL je mali i sazet jezik kao stvoren za MCU-ove, ali tu vlada C. Ja sam za osnovu uzeo najstariji standard ISO 7185 koji je najblizi referentnoj definiciji PASCAL-a koju je dao njegov tvorac Nikolas Virt. Zapravo vise sam se drzao Virtove definicije.

Kada sam poceo, to je bio megalomanska zamisao. Jedan covek iz hobija tesko da moze da uradi ovo sto sam zamislio.

Zato sam od nove godine nastavio, ali sam smanjio apetite. Tu sada dolazi preispitivanje mojih odluka, pa ocekujem komentare i savete nekolicine vrsnih forumasa cije postove stalno pratim.

Prva odluka je bila da zadrzim drasticnu strogost u pogledu kompatibilnosti tipova koju je uveo Virt, a koja je ublazena kasnijim standardima PASCALA.

Ovo treba da iskljuci besmislene iskaze kada se mesaju babe i zabe. Jednostavno, nije dozvoljeno dodeliti oznacenu vrednost neoznacenoj, dok je obrnuto moguce samo, ako oznacena vrednost svojim tipom obuhvata neoznacenu. O dodeljivanju karaktera celobrojnim vrednostima i slicno nema ni govora.

Druga odluka je da se tip vrednosti oznacenog bajta (shortint) prostire od -127 do 127. Isto vazi i za dvobajtne i cetvorobajtne vrednosti. Pitate se zasto ne od -128 do 127. Razlog je prost: ako je X = -128 onda Y := -X daje varijabli Y vrednost -128. Ovo je glupost, to je uocio Virt i kod njega je na isti nacin definisan skup vrednosti oznacenih brojeva.

Treca odluka je da skupove ogranicim na najvise 32 elementa (4 bajta). Moja procena je da za MCU aplikacije ne treba vise.

Cetvrta odluka je da nizova ogranicim na 256 elemenata (0..255). Ovo je dovoljno u najvecem broju slucajeva, a ako zatreba duzi niz, onda se mra preci na dvodimenzionalni niz ili visedimenzioni, ali ako ima dovoljno RAM-a. Razlog je jednostavnije pisanje kompajlera, nemam dva slucaja kod nizova: za manje od 257 elemenata i vise od 256.

Peta odluka je najdrasticnija. Ogranicio sam broj clanova u izrazu na 2. Moze Niz[a+b] := c+d, ali ne moze a := b+c+d. Izraz sa vise clanova mora se razbiti u dva iskaza. Ovo je rezultat mog ubedjenja stecenog analizom stotina hiljada redova izvornog koda, koje sam napisao za ovih 7-8 godina. Ne secam se da mi je vise od 0.5% slucajeva trebao izraz u iskazu sa vise od 2 clana.

Sta dobijam time, pa nemam medjurezultat koji moram da pamtim na steku. Ovim sam iskljucio mnoge slucajeve koji se pojavljuju prilikom kompajliranja. Sto je jos vaznije, kompajler treba testirati za sve slucajeve, a to bi bio dosadan posao u nedogled.

I uzgred, imao sam, a jos je imam, nedoumicu kako tretirati unarni operator not (u C-u ~) sobzirom da zelim totalnu strogost po pitanju tipova. Ovo zato sto je not x = -x-1, pa se moze smatrati i aritmetickim operatorom, ali i ligickim jer deluje jednako na sve bitove podatka.

Tako je -not x = x+1.

Dakle, sta vi mislite. I sa ovim ogranicenjima ceka me tezak posao, isplati se ako ih ocenjujete da nisu ogranicenja i za aplikaciju.

Pozdrav.

Ja ništa od ovoga ne vidim kao oganičenje. Jednostavno, da ne trošim C, da je tvoj kompajler dobar a džabe ;) ne bih video nijedan razlog koji bi me naveo da ga ne koristim. Prva odluka je u redu. Podržavam mada se ni sam često ne pridržavam toga. U brzini valjda. Kompajler mi generiše upozorenja a ja ih obavezno proverim.
Druga je po meni ne preterano bitna. Ako ti kažeš da je opseg vrednosti takav onda je to to. Držiš do principa da sve bude regularno i logično.
Treća i četvrta tebi olakšavaju posao a MCU aplikacije ionako ne zahtevaju nešto više. Bar meni ništa više nije trebalo. A i uvek ima workaround...
Peta je po meni malo sporna jer volim da izraz smestim u jedan red. Lakše je za čitanje. Skoro sam upoređivao veličinu koda dobijenu prevođenjem najpre kompleksnog izraza i potom razbijenog izraza na nekoliko manjih. C kompajler je generisao neznatno kraći kod za kompleksan izraz. To takođe nije toliko bitno ali čitljivost jeste bolja. Eto.. Pošto je za hobi podržavam ali i sam znaš da C dominira.. Možda bih mogao da pomognem testiranjem ako ništa drugo.

Potpis

gorankg

Hvala ti na podrsci.

Sada sam na samom kraju iskaza dodele, bavim se dodelom stringova i vecih struktura (nizova i zapisa).

Neocekivani, zaista je malo efikasniji (ocekivao bi vecu efikasnost) kod jednog iskaza u odnosu na dva ili vise razbijenih. Razlog je prost: medjurezultati se cuvaju na steku a pristup njima je skuplji nego direktno memorijskim lokacijma.

Sto se tice upozorenja - ona ne mogu bas sve. Ako napises:



Kompajler te nece upozoriti o mogucoj gresci.

Pozdrav.

Microchip XC8 generiše upozorenje za overflow. Sad sam proverio.

Potpis

gorankg

@korak, ako ces dda ga pravis za sebe onda je potpuno nebitno koje i kakve limite ces da dobijes. Pisanje kompajlera je ozbiljan posao i mnogo je kompleksniji od proste translacije jednog niza naredbi u drugi. Poenta kompajlera, danas, je da shvati tok programa i postujuci taj tok programa napravi najbolji moguci binarni kod koji ce raditi isto to ... ta vrsta optimizacija (za brzinu, za duzinu, za ..) je ono sto cini kompajler kompleksnim, sto se tice direktne translacije iz tante u kukuriku to realno danas i nije neki ogroman problem, posebno kada je strongly typed jezik u pitanju (poput paskala), bljac/leks/bizon i par dana preko toga i voila .. ... ali kako optimizovati delove koda za raclicit procesor, iskoristiti osobine procesora koje jedan ima a drugi nema etc .. to je vec druga prica

no kao sto rekoh, kada ga radis za sebe sve je to potpuno nebitno

e sad, ako hoces da pravis pascal compiler koji ce i drugi da koriste, za pocetak nije lose da zdraknes neke open source pascal kompajlere, sigurno ih ima vise nego jedan, da ne moras da ides ispocetka (nebitno sto su za x86) i ustedis sebi puno posla ... sto se tice tvojih limita

1. pascal je strongly typed, to je da bi se brze prikazale semanticke greske prilikom kompajliranja (tako sto se deo semantickih gresaka iskonvertuje u sintaksne), ko hoce da pise pascal mora da prihvati da je strongly typed tako da ovde nema nikakvih problema. ja licno ne volim ni pascal ni modulu2/3 bas iz tog razloga mada nemam problem da ih koristim i dan danas (freepascal+lazarus) za neke uopste ne-male projekte

2. mislim da ti je to gubljenje vremena. ako covek koji pise kod za mikro-freaking-controller ne zna sta je bajt i kako se reprezentuje negativna vrednost i nije svestan kako to funkcionise nije mu mesto za racunarom. Time sto ces da uvodis takav "limit" ti pravis od ljudi koji nesto znaju volove, ti imas dodatno posla a pomazes ljudima kojima realno nije mesto tu, oni neka klikcu po VB-u i neka uzivaju

3. i bil gates je rekao 640k je dosta za vjek i vjekova pa ja sad imam 24G u masini i 1G u mobilnom telefonu

4. ako se ja dobro secam original pascal je imao limit za 256 .. meni se ta ideja ne svidja no nije problem, ja bi ipak isao sa 2 bajta za index ili bi uveo 2 tipa array (array i arrayX) gde je jedan dvobajtni a drugi jednobajtni, ali u regularni array bi stavio dvobajtni index

5. ako pravis kompajler za sebe ovo je skroz ok, ako pravis kompajler za nekog osim sebe ovo nikad nece proci, niko nece hteti da koristi kompajler koji ne moze da izracuna i optimizuje racunicu obicnog matematickog izraza. Imas sigurno brdo primera na netu kako to da napravis da radi ok, ima bar 2-3 optimizacije opisane na netu koje mozes da iskoristis

6. not treba da izvrne sve bitove, dal ce rezultat numericki biti - ili ne to je druga prica, - isto treba da se ponasao kao klasicno u asm-u, bez ikakvih budzevina, za krajnje vrednosti, ako korisnik ne zna kako funkcionise cpu, neka ide da klika po vb-u

sta mislim o tvom pascal kompajleru za motorolu, ne znam, ja ga necu koristiti, motorola je dala vrlo jasno do znanja sta misli o ne-biznis korisnicima tako da ne vidim razlog zasto bih ja trosio vreme i novac sa njima, uvek cu pre pisati asm nego pascal, posebno pre nego pascal koji nema linker koji ima milion limita, koji nema optimizaciju .. a inace dokle god postoji C kompajler za pristojne pare / dzabe, pascal meni ne igra ulogu ... ne shvati me pogresno, ne mislim da je generalno beskoristan, verovatno ce neko naci o korisnim, eto ti prvi, no meni je pored C-a za embedded pricu pascal smesan

sta mislim o pisanju pascal kompajlera generalno, mislim da je poceti od pocetka borba sa vetrenjacama, ima toliko primera .... ako izignorisemo freepascal, gnupascal i jso par veliki ...
ima malih kompajlericica odlicnih za preuzeti kao osnovu

imas npr brdo pascal kompajler sorsova ovde: http://exmortis.narod.ru/src_compilers_eng.html
sigurno ti je lakse da prepravis neki postojeci koji radi za 8086 nego da pises ispocetka i resavas po stoti put stvari koje su ljudi resili vec ko zna koliko puta

nisam bio od neke velike pomoci ali .. trazio si misljenje

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Naravno, savremeni kompajleri optimizuju grupe iskaza. Narocito je vazno da prepoznaju petlje i brojacku varijablu i da sve u vezi sa njom optimizuju. Kada uporedim pojedinačne iskaze, moje i one koje prevodi CodeWarrior, prednost je na mojoj strni. Ali ako pogledam grupu iskaza tu ima zaprepaščujućih optimizacija. Počev od trivijalnih da pamti u kom se registru nalazi vrednost neke varijable i da joj ne pristupa u memoriji, do toga da menja redosled iskaza, da neke izbacuje i t. d. Sve sam to proučavao, ali nije jednostavno za hobi.

1. To što je strog po pitanju kompatibilnosti tipova mu je samo prednost, to je osobina viših programskih jezika (C je srednjeg nivoa u tom pogledu). Najviše grešaka sam nalazio baš time uzrokovane kada sam dibagirao neki C program jedne firme u Beču, čudo kako je program olako pisan. Suprotno tebi ja volim strogu tipiyaciju. U suprotnom pišu se matematički izrazi za koje ne važi da ako je a = b onda je i b = a. Primer la = ~wa (la je oynaceni long, a wa neoynaceni word) pa posle toga je ~la <> wa, a trbalo bi da bude jednako. Dakle C nije matematicki korektan.

2. Ali gotovo svi smatraju da oznacen karakter treba da ima opseg vrednosti od -128 do 127. To je opseg koji obuhvata sve vrednosti, ali u PASCALU je taj opseg od -127 do 127. Ovim se izbegava greska kod dodele oznacenog karaktera oznacenom karakteru sa = -sb, ako je izvorna vrednost sb = -128. Osim toga jednostavniji su problemi oko proširenja znaka. Na ovaj način se ima jednak broj pozitivnih i negativnih vrednosti (skup je simetričan) jer 0 jednako pripada i pozitivnim i negativnim brojevima, -0 = 0.

3. Mehanizam za veće indekse postoji, jer ako se radi o nizu elemenata složenog tipa, recimo dužine 15 bajta, onda se adresa računa kao indeks*15+Niz. Ipak za sada ostajem pri ovom ograničenju kako bi imao što pre gotovu i testiranu prvu verziju, a veće indekse ću dodati kasnije.

4. Još od prve definicije PASCAL-a nije bilo ograničenja u indeksu, to je prepušteno implementaciji.

5. Možda će privući nekoga jaka tipizacija, postojanje stringova kao preddefinisanog tipa, postojanje skupova koji znatno olakšavaju manipulaciju sa bitovima i postojanje modula kao programskih struktura, a ne include fajlova koji nisu programske strukture već tekstovi koji se insertuju na mestu te direktive, i u vezi sa tim hedet fajlovi. Zatim linker razvijen 60-tih godina koji se suštinski ne menja zbog tako potrebne kompatibilnosti, i užasa kada shvatiš da ti je linker prijavio grešku. PASCAL koristi linker, ali mu on u suštini nije potreban, kao što ga ni ja ne koristim.

6. Slažem se sa tobom, ali onda not (~) ima smisla samo u izrazima neoznačenih brojeva.

Pogledao sam mnoge PASCAL-e sa neta, one namenjene raznim mikrokontrolerima (od 8-bitnih pa nadalje) i sve sam ih testirao. Oni su uglavnom bazirani na C-u, samo je notacija prilagodjena PASCAL-u. Shodno tome mnogo toga im nedostaje.

U svakom slučaju hvala ti i pozdrav.

1. da pricamo o matlabu ili fortranu to bi imalo smisla, ali to sto "dodela" nije matematicki ispravna unazad nema smisla kao argument. bilo koja druga jednosmerna transformacija ima isti "problem", no to je namerno. implicitno konvertovanje tipova je jedan od razloga zasto je c toliko zastupljen u tom trzistu, a to da postoje losi programeri, to ja nikako ne mislim da treba resavati limitima, virtualizacijom i sakacenjem vec boljom edukacijom i boljim "rešetom".

2.iskreno, ne secam se kako je u pascalu. ako me sluzi pamcenje 127+1 je greska a ne ni -127 ni -128, nemam odnos prema tome, pascal je geberalno imao bounds check ali taj runtime kosta, kada je embedded u pitanju ja mislim da je ta cena prevelika. no, nemam ozbiljan stav, kako god napravis bitno je i da dokumentujes

3. to j 100% dobar stav, lako je posle prosiriti

4. isto kao [3] lako je posle promeniti

5. nikako se ne slazem no ima nas raznih :)

6. realno ne.. za strongly typed jezik not ima smisla samo za boolean, ako se koristi kao bit operator treba da izvrne bitove bez obzira na tip podatka... to je malo kompleksno za uglaviti u strongly typed jezik i vrlo cesto ni ne postoji odim za bool. fora je sto tebi u embedded-u treba bitwise not i onda tu moras da napravis izuzetak

7. hm vecina pascala koje sam ja video su daleeeeeeeko od c-a ali da svasta im fali, no i dalje mislim da su blizi resenju od praznog papira a neki vec implementiraju neke optimizacije.

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

1. I to je jedna od karakteristika koje dele više programske jezike od onih srednjeg nivoa. Neko voli da mu je ‚‚široko oko guše‚‚ jer je dobar poznavalac C-a i mašine pa se tu oseća kao riba u vodi. Problem je sa onim drugima. Nikakav limit nije što nekompatibilni tipovi ne mogu da učestvuju o operacijama niti u dodeljivanju. To je definicija i to je tako. Problem je nastao što je Virtova definicija PASCAL-a imala samo integer koji je odredjen mašinom za koju je kompajler. On uvodi podintervalne tipove kojima je integer obuhvatajući tip. On ostavlja implementaciji kako će se baratati tim podintervalnim tipovima.

2. Da, 127+1 jeste greska, ali i -127-1. Problem je u tome što definicija zahteva proveru greške uvek. No to bi iskomplikovalo kod znatno ga uvećavajući. Taj kod za proveru se može kompajlerskom direktivom ukinuti, kada se posle testiranja ustanovi da u programu nema prekoračenja. Inače sve ovo nije usaglašeno sa procesorom, naime on generiše fleg za prekoračenje označenih brojeva kada se vrednost, oduzimanjem 1, promeni sa 0x80 na 0x7f odnosno sa -128 na pređe na 127.

5. Ne insistiram, samo kaćem možda. Ono što sam naveo već je davno navedeno kao potrebne osobine programskih jezika date od najvećih stručnjaka ove oblasti. Ali moć navike je vrlo jaka, ali ne mogu da zamislim da se C koristi i 2050 god.

6. U PASCAL-u su logički operatori za tip boolean i celobrojne tipove isti. To je zato što je false = 0x00, a true = 0x01, a ne bilo koja vrednost različita od nule.

7. Izgledaju daleko, ali kada pogledam stringove, a oni su u formatu C-a sa završnom nulom. Neki nemaju skupove, a mnogi ne mogu vrednost složenog tipa da dodele drugom složenom tipu, kao Niz1 := Niz2 gde su oba niza istog tipa. i tako još niz sitnica.

Pozdrav.

1. kako se uzme, ako ces praviti kompajler koji ne zna sta je float, why bother?

2. bas zato sto cpu generise flag na -128 ja bi ostavio tako. teoretski znacaj simetrije u odnosu na prakticni znacaj velicine i brzine koda, po meni tu nema pitanja uopste

5. kao sto i danas ima asm tako ce i 2050 biti c. sa novim trendovima kompajliranja u javascript i uvodjenje debila u programirznje sve je moguce

6 dakle not rsdi 0<->1 i to je t0

7. cstring je logicniji za rad, kopiranje kompleksnih tipova se lako implementira... sve u svemu ne kazem ja da su idealni vec da su zgodni kao pocetak,lakse njih prilagoditi nego sve ispocetka

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

1 O float tipu za sada ne razmisljam. On se lako implementira sobzirom da se realizuje pozivom sistemskih funkcija.

2 Da, ali C po definiciji ne proverava prekoracenje i to njemu nista ne znaci. Ugradjivanje kod za proveru prekoracenja vrlo je skupo, a pitanje je i sta da uradi MCU kada se to desi - da zaustavi masinu usred posla?

5. Secam se 80-tih godina, citao sam prognoze strucnjaka iz oblasti racunarske tehnike, prognozirali su nezamisliv napredak softvera i pitali se da li ce to moci da prati razvoj hardvera. Totalno su omasili, desilo se obrnuto, mocan hardver je dozvolio softverasima da komotno pisu softver koji se zbog toga usporeno razvijao. Ako su oni omasili, ko smo mi da dajemo prognoze.

6. Nisam razumeo.

7. C format stringa ne dozvoljva da imas znak sa ordinalnom vrednoscu 0. Kada prvi znak oznacava duzinu stringa, onda je on relativni pointer na kraj stringa. Ovo omogucuje znatno efikasnije operacije sa stringovima. Testrao sam, i to se potvrdilo. Uostalom svako moze u C-u da napravi niz karaktera gde prvi karakter oznacava duzinu stringa, i da proba lakocu rada sa takvim stringovima. Na kraju, kada se string salje nekoj periferiji koja ocekuje 0 na kraju, tada izvrsis konverziju.

Uzmi primer Str = Str+Ch.

Uradis Str[0]++, izracunas adresu Str+Str[0] i u nju upises Ch. Prostije ne moze biti.

Ne znam koliko si upućen ali programski prevodioci nisu ni malo naivna tema. Dok dođeš do optimizacije koda ima da se napatiš debelo. Ovde pri dnu stranice imaš video lekcije koje će ti mnogo pomoći za leksičku, sintaksnu i semantičku analizu, a alati koji su korišćeni postoje i u verziji za C++. Za generisanje koda ćeš morati sam da se snađeš i da poznaješ ciljanu arhitekturu. Tabelu simbola ćeš takođe morati sam da osmisliš i implementiraš funkcije za podršku prevođenju. Za početak pročitaj nešto o LARL(1) gramatici, SHIFT/REDUCE konfliktima i kako da ih prevaziđeš, o parserima uopšte i generatorima parsera (mislim da nema smisla pisati kompletan parser od nule), pa onda o generisanju koda itd. Optimizacija je poslednja stavka tek kada sve ostalo funkcioniše odlično.

@korak Ne znam sta da ti kazem, sumarum je da hoces da napravis kompajler koji radi samo sa integerom, ima striktne tipove ali ne i provere koje ti striktni tipovi definisu, koji ima limite na velicinu skupova i nizova i ne ume da isparsira najprostiji izraz ... nemoj pogresno da me shvatis ali meni to deluje kao translator iz paskalolikog jezika u asm a ne na kompajler. to sto ce da ti radi kompleksnavar1 := kompleksnavar2; .. radi to i u C-u samo malo drugacije ( memcpy(&komplesnavar1, &komplesnavar2, sizeof(kompleksnitip)); ) i nije neka super prednost :( ... bice strong type, super, sta je prednost strongly typed jezika u varijanti kada nema real time provere? (sta da radi sa realtime greskom - hitne exception, iliti u jeziku mcu-a interapt) ...

Ne kazem da je to nekorisno ali meni licno prilicno nezanimljivo.. posebno, ti kazes da imas 6 limita / odluka .. ali ako ti kazes da neces imati izraze, sta da ocekujemo kada su u pitanju strukture? da li ces imati strukture? pointere na strukture? nizove struktura? da li ces moci da imas kompleksne strukture koje za clanove strukture imaju druge strukture, pointere na sebe ili druge strukture, nizove kompleksnih struktura? Ili se to podrazumeva da nemas kada ne mozes da izracunas a:=b+c+d ? Ako se ja dobro secam Virtov originalni paskal ima strukture kopleksne koliko i bilo koja implementacija paskala. Funkcije? Procedure? Ja znam nekoliko ljudi koji su poceli sa pascal kompajlerom pa su zavrsili sa nekim kontrapcijama koje su zvali "mikin i zikin jezik" i koje su imale 2-3 korisnika .. toj dvoici troici je to bilo ultra korisno i mega im je skracivalo vreme rada, ti to pravis prvenstveno za sebe, pravi kako tebi radi posao ... ja sve sto sam pisao je za varijantu da ga koristi jos neko .. mada moram priznati da od jedno 400-500 ljudi sa kojima komuniciram na raznim forumima vezano za mcu programiranje znam samo 2 koji pisu u paskalu (i koriste oboica mikroPascal) i jednog koji koristi onaj JAL iil kako se vec zove (lik ga je pravio zato sto ne voli C pa je pravio Pascaloliki jezik i sa svim svojim idejama i limitima napravio JAL) ..

6. izvini ali nisam imao komp ovih dana pa sam cukao sa nexus-a, koliko god je korisna sprava sa mojim bangavim debelim prstima kucanje uopste nije zabavno ... elem hteo sam da kazem da ako je true uvek 1 i false uvek 0 onda not() tj ~ ili ! koji vec literal uzmes treba 0 da pretvara u 1, 1 u 0 a za sve ostale vrednosti da vrati gresku. Ako hoces "strongly typed" to je to ... fora je sto "strongly typed" kada je mcu u pitanju nema preterano mnogo smisla, sto se mcu-a tice (posebno tvoje osmobitne motorole) imas byte i to je to, a kako ces ti da tumacis sta je u memoriji... no, sve to ti vec vrlo dobro znas ..


@ac1bd4, zna on sigurno da koristi lexx/yacc/bison i ekipu, ne verujem da je krenuo da pravi parser rucno, jeste da covek vole da sve radi sam ali toliko zaludan nije

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

@ac1bd4

Naravno da ne. Kupio sam neku editorsku komponentu namenjenu raznim programskim jezicima Od TMS-a, TMS Memo koja umesto parsera ima AdvPascalMemoStyler gde se definisu pojedina svojstva za grupe reci i razne znakove. Odmah da kazem da nisam zadovoljan, usporava rad sa povecanjem duzine teksta.

Evo sta se moze, na primer, dekarisati (preskacem konstante)

type
tRadniDani = (ponedeljak, utorak sreda,cetvrtak, petak);
tRec = record
ba : byte;
sa : set of tRadniDani;
RadniDani : array[tRadniDani] of record
PocetakRada,KrajRada : 1..24;
end;
end
tNiz = array of [0..9] of tRec;

tPortA = set of (Ulaz0,Ulaz1,Ulaz2,Ulaz3,Izlaz0,Izlaz1,Izlaz2,Izlaz3);

var
Niz : tNiz;
PortA : tPortA absolute 0;
PortADD : tPortA absolute 1;
ba,bb,bc : byte;

i primena

PortA := [];
PortADD := [Izlaz1,Izlaz2,Izlaz3];

PortA := [Izlaz1,Izlz3];
ba := PortA[Ulazo..Ulaz2];
PortA := PortA - [Ulaz3];

ba := Niz[bc].RadniDani[utorak].KrajRada - Niz[bc].RadniDani[utorak].PocetakRada;

U izrazu iskaza imas dva clana. Clan nije samo jedno ime, to se vidi iz sintakse i PASCAL-a i C-a. Tako je jedan clan Niz[bc].RadniDani[utorak].Krajrada

Da ne komplikujem dalje sa visedimenionim nizovima i pointerima.

Nadam se da si iz ovoga video da se ne radi o obicnom preslikavanju na asembler.

Takodje stvarni parametri funkcija i procedura mogu biti izrazi ograniceni na dva clana.

Ovim skresavaš max. dužinu stringa na 127.
Kome je uopšte zanimljivo toliko skraćenje?

Drugo, šta je sa primjerima kada spajaš dva stringa, ili umećeš string u string, ili upoređuješ itd.?
Stvara se dodatni posao oko sabiranja i ažuriranja tih karaktera koji predstavljaju dužine stringova, moraš shiftovati indekse itd...?
Time jednostavno generišeš mnogo više problema nego što ih rješavaš/olakšavaš.
Ako ti treba negdje dužina stringa možeš da je čuvaš u nekoj varijabli van stringa, zašto bi je gurao u string?!


Tako se ne radi sa stringovima i prosto da prostije ne može biti si napravio nekontrolisano sjebavanje memorije.
Na adresi Str+Str[0] kompajler je mogao smjestiti neku drugu varijablu ili odatle počeo da popunjava neki drugi niz ili string.
C će ti naravno dozvoliti da šaraš po memoriji kako god hoćeš i šta god hoćeš, tako da ćeš ti zaista uraditi Str = Str + Ch, samo što ćeš time sjebati ono što se u memoriji nalazilo iza tog Str stringa.
Kompajler će ti možda dati neki warning, a možda i neće (uglavnom neće), zavisi u kojoj su astralnoj kuci tog dana strelac i vodolija...

Ja sam vodolija.

Dok sam radio u asembleru stringove sam pravio u oba formata. Naravno sve operacije sa njima se rade u posebnim procedurama. Veruj mi da su one bile jednostavnije kada sam imao duzinu na mestu prvog znaka.

Duzina stringa je ogranicena na 255 znaka a ne na 127. U DELPHI-ju redovno koristim string[255] koji je bas onakav kakav opisujem, dok je tip string (bez navodjenja duzine) dinamicki i neogranice, i nikad mi nije trebao, sem kod nekih komponenti koje imaju takav tip nekih svojstava ili parametra tog tipa u nekim metodama. Dakle, i tu mi je bio sasvim dovoljna duzina stringa od 255 znakova, a za MCU-ove je itekako dovoljna.

Nema "ako ti treba duzina stringa", ona ti uvek treba za svaku operaciju nad stringom.

Kada insertujes karakter u string, u oba slucaja (za oba formata) moras da pomeris udesno sve znakove od mesta gde insertujes string. Nema bitne razlike.

Vec smo razmotrili problem kontrole prekoracenja vrednosti bilo varijabli bilo indeksa. Definicija PASCAL-a to zahteva, ali je onda kod dosta opterecen proverama. Ako je deklarisana duzina stringa 2^n, onda je ova provera trivijalna: uvecanje duzine stringa vrsis po modulu 2^n sto se svodi na jednu and logicku operaciju nad duzinom sa 2^n-1 i to ti nece dozvoliti da izadjes van deklarisane duzine stringa.

Ja ovim ne kritikujem C format stringa, jednostavno se drzim onoga sto je praksa u PASCAL-u. Osim toga radio sam i sa jednim i drugim formatom i iznosim moje iskustvo i nista vise. Da li je tvoje iskustvo da ti uobicajeno trebaju stringovi duzi od 255 znakova - sumnjam.

Pozdrav.

Treba ti ako nemaš terminator na kraju stringa.


Ne uobičajeno, ali kad mi zatreba nemam namjeru da koristim neke akrobacije sa 'kratkim' stringovima.
U čemu je poenta?


Pa tvoje potrebe su veoma sužene u odnosu na ono šta sve ljudi rade sa mikrokontrolerima i u odnosu na ono šta se sa njima uopšte može raditi.
Prema tome, svako razglabanje o tome da li je nešto uopšteno dobro je besmisleno, pošto je fokus kompletno na tome da li je tebi ok ili nije.

Ja recimo neki ovakav kompajler ni u ludilu ne bih koristio, ali ako je tebi ok i tebi vrši posao - samo napred, nema ništa loše u tome da sebi napraviš alat koji je za tebe najbolji od svih. Čak naprotiv.
Nebitno je šta drugi o tome misle.

Terminator na kraju stringa? Pa sta je to nego, svojim mestom u stringu, oznaka duzine stringa.

Jos gore, tu nije eksplicitno navedena dužina stringa.

Kako proveravaš kompatibilnost stringova u dodeli u iskazu: StrA = StrB+StrC; Prođeš kroz StrB do terminatora pa imaš dužinu StrB, to isto i za StrC, pa sabereš dužine i to treba da bude manje ili jednako od deklarisane dužine StrA. Koliko procesorskog vremena potrošiš a još nisi ni počeo sabiranje.

Da stvar bude komplikovanija ne smeš direktno na StrB da dodaješ StrC (u početku je Mikroelektroika pravila tu grešku, sada su ispravili) već moraš da napraviš dinamičku kopiju StrB i na nju da dodaješ StrC. Ako su ovi stringovi ‚‚dugački‚‚ (mada niije malo ni 255 znakova) eto posla za MCU.

Ne negiram manu što je string ograničen, ali ne zaboravi da ovo radim iz hobija i za 8-o bitni mikrokontroler sa nekoliko KB memorije. Pri tome ne želim svoju volju da namećem, samo diskutujemo, ali bez zgražavanja.

Meni smeta što C nema skupove, ali ti si navikao da akrobacijama to prevaziđeš i dobro ti je, a ja se ne zgrazavam - jednostavno to je tako.

Potrebe mi nisu sužene, naprotiv, napravio sam kontroler lifta koji kada kontroliše kretanje kabine to radi u interrupt-u na 1ms, i ta interrupt procedura ima 17KB koda, doduše ne izvršavaju se svi kilobajti odjednom jer postoje brojna uslovna granjanja. Ja, kada koncipiram program jednaku pažnju, a možda i veću, posvetim strukturi podataka pa tek onda strukturi programa. Ovim pristupom izvlačim skoro maksimum iz MCU-a. Ovo je samo poslednje što sam završio, ilustracije radi.

Inače igram se, baš kao hobista, sa kinetisom MK60DN512ZVLL10 ali za njega nemam posao (ne koljem vola za šniclu), u izgledu je nešto ovog leta (neka mrežna aplikacija). Videćemo.

Pozdrav.

subset, inset, join, intesect ... pricamo o prostim bbitwise operatorima i bitovima sa imenom?! vecina c kompajlera ima mogucnost za imenovanje bitova no C je potpuno nebitan ovde, ti pises paskal kompajler ..

ti realno pravis kompajler za prilicno patetican (za danasnje uslove) kontroler i neke fancy igrarije tu ne mozes da izvodis .. sve to ima smisla, i pisati kod za taj mali mcu u asm-u, i praviti pascal sakati kompajler etc etc .. ja bi licno za te malisane pre koristio basic kompajler nego pascal (mnogo lakse za napisati) i dodao na taj basic svoje ektenzije.. u svakom slucaju, sta god da bi radio ostavio bi mogucnost da kompajler pretvori racunanje izraza u kod a ne bi zahtevao da ja razbijam taj kod u segmente i ja mislim o tome gde cu da cuvam medjurezultate .... ako cu da razbijam ja izraz onda cu radije da napravi mali forth kompajler ili jos bolje interpreter :D

ovo za stringove - jeste ako gledamo hc11 koji je dizajniran '80tih (izasao '85 ako se ne varam), ali realno ti radis strcpy u svakom slucaju a ako radis strcpy kompajler treba da ume da koristi potencijalne mogucnosti mcu-a da uradi taj cpy brze ili cak i uz pomoc externog hw-a (dma) ... i tu je terminator cesce koristan od duzine

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Pošto se igram sa kinetisom (ARM+DSP+...) 128KB RAM 512KB flash i gledam prevod C koda. I sta vidim, razmaženi softveraši neke segmente prevode manje efikasno nego što bih ja uradio, a zašto bi, jak MCU, možeš da arčiš flash, brzina dovoljna, oni brzo završili posao i svi zadovoljni.

A opet gledam Keil za 52-ojku, pošteno odrađen posao, nema steka nema direktnog pristupa memoriji ali se ljudi potrudili da naprave dobar kompajler. Slično je i sa nekim dobrim kompajlerima za PIC, pa i za AVR gde doduše obilje registra olakšava pisanje kompajlera.

A ista firma FreeScale je C kompajler za 9S08 koji siroma ima samo 8-o bitni akumulator i 16-to bitni indeksni registar i stek pointer pošteno uradila sa nekim iznenađujućim optimizacijama, doduše za mene su iznenašujuće.

Inače, čitao sam izveštaj početkom 2012, za 2011 god, od proizvedenih i prodatih svih MCU-ova 55% su 8-o bitni. Oni postaju rasejani po mašini, automobilu i t. d. i umreženi su sa nekim 32-bitnim koji radi ‚gospodske funkcije‚ komunicira sa gazdom (čovekom) i izdaje naloge 8-o bitnim sirotanima. Često ih i ne prepoznajemo kao MCU-ove u nekim sklopovima. Oni su dobar interfejs sa mnogobrojnim senzorima.

Dakle, nemoj i ti ove sirotane da nazivaš patetičnim oni odrađuju jedan vrlo važan posao i oslobađaju toga glavni MCU kako bi on mogao da odigra svoju pravu ulogu kao interfejs prema coveku preuzimajući njegovu ulogu u upravljanju.

Mislim da će taj, da ga nazovem organizam, uvek biti takav, gde su svi važni, i da će u budućnosti razvoj 8-o bitnih ići u smeru ugradnje raznih senzora i povećanja mogućnosti komuniciranja. Distribuirana obrada podataka je odavno pobedila koncept centralizovane obrade.

ne mislim ja nista lose kada kazem da su pateticni, a sto se tice tih prodadit, pre neki dan je bila neka statistika koja kaze potpuno suprotno

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/