C absolut cimu valtozo generalasa
Moczik Gabor
progzmaster at freemail.hu
Wed Jan 7 18:12:52 CET 2004
Andras Tantos wrote:
>>Mondtam hogy nem szabvanyos, de ha mikrokontrollerre forditasz, akkor
>>altalaban fontosabb hogy gyors, hatekony legyen a kod, es ennyi
>>szabvanytalansagot meg lehet engedni.
>
> Ebben nincs vita. Ha *kell* el lehet terni a szabvanytol, foleg, ha a
> hordozhatosag nem szempont. Ez igaz a felhasznalora. A
Altalaban uC-re nem fontos.
> fordito/nyelv/kornyezet fejlesztoi viszont haromszor el kellene
> gondolkozzanak minden nem szabvanyos megoldas beepitesen. Lasd fenti pelda:
Altalaban nem szoktam nem-std megoldasokat feleslegesen beepiteni, de amit
irtam eleg egyertelmu mind fordito, mind felhasznalo szempontjabol.
> All bit manipulation instructions will first read the entire register,
> operate on the selected bit and then write the result back to
> (read-modify-write (R-M-W)) the specified register. The user should keep
> this in mind when operating on some Special Function Registers, such as the
> Port Pin Register
>
> En is pontosan errol beszeltem: a megoldas nem altalanos, bizonyos tipusu HW
> regiszterek kezelesere nem alkalmas. Akkor viszont szebb, konnyebben
> karbantarthato kodot eredmenyez az, ha nem haszalod ki ezt a lehetoseget, es
> minden HW regisztert sajat koddal ersz el. Es megint csak: a fordito dolga
> lenne az, hogy ezeket a kodreszleteket optimalis kodda forditsa az adott
> porcesszoron, pl. ha vannak, ilyen bit-utasitasokka. Egyebkent te is irod,
> hogy az x|=0x40 is bit-muvelet lesz, tehat a fordito meg is teszi neked ezt
> a sziveseget.
Es? Ez nem a deklaracio hibaja. Ezt ASM-ben is meg tudod serteni, ha bit
manipulalo utasitast hasznalsz. Ez mar architektura specifikus dolog, ha a C
forditod van olyan intelligens, akkor lehet hogy eszreveszi, es Warning-ozni
fog.
> Nem errol van szo. Ugy altalaban nem szerencses, a fordito viselkedesere
> biznod a program mukodeset. (pl. if ((MyPtr != NULL) && (MyPtr->MyData ==
> 3)) {...}). Egy verzio valtas, vagy a forditonak adott forditasi opciok
> valtozasa eleg ahhoz, hogy a programod mukodokepesbol hibassa valjon. A
> forraskodnak egyertelmunek kell lennie, azaz ne lehessen olyan (hibatlan)
Ha egy fordito ebbol rossz kodot fordit az hibas. Ugyanis a szabvanyban az
all, hogy ha egy feltetel erdmenye mar eldolt, akkor a tovabbi reszek nem
ertekelodnek ki. Tehat ANSI C szerint a kod hibatlan. Mindenesetre tenyleg
nem kovetendo pelda.
> az a teny, hogy a megoldas csak bizonyos tipusu regiszterek eseten mukodik
> helyesen, viszont ha raszoksz a hasznalatara, egy-ket olyan helyen is
Bizonyos esetben _nem_ mukodik helyesen. Azert javitok, mert azert a tobbseg
eseten mukodik. Egyebkent a PICC gyari header fajljaiban fel van sorolva az
összes (?) bitre vonatkozo deklaracio, szoval ha nem akarod nem is kell
hasznalni, beincludolod a headert es elfelejted hogy van ilyen utasitas. :-)
> regsziter eleresehez. Ugyanakkor van olyan megoldas, ami (eleg) hasonlo
> koddal elerhetove teszi mindket tipusu regisztert, es az altalad leirtak
> alapjan jo esellyel ugyanazt a kodot eredmenyezi, mint a speci szintaxis
> hasznalata.
Marmint? Az x|=0x40-re gondoltal? Most tisztaztuk hogy ugyanazt forditja
belole, es akkor az is hibas lesz. Mert ez arch fuggo dolog.
> A bit-mezoket adat-tomoritesre (optimalis memoria-kihasznalasra) es nem HW
> regiszterek SW leirasara talatak ki. Tudtommal a szabvany nem rogziti a
> bitmezok kiosztasi sorrendjet (MSB first, LSB first, pl.). Ha jol tudom,
> csak annyit ir le, hogy nem szabad addig uj int-et nyitni, amig a
> megelozoben van hely. De talan meg ez is legalis:
Igazabol en meg ugy tudom, hogy akkora valtozot fog hasznalni, amiben a
felsorolt bit-mennyiseg elfer. Ha nincs ekkora, akkor nem tudom, de nem is
erdekes, mert akkor mar biztos nem hw leirasra kell.
A sorrend meg szerintem architektura fuggo. Ha nem fejlesztesz ilyen
torzszulott processzorra amin lehet valtani a sorrendet, akkor szerintem
hasznalhato.
> Ezzel viszont nem ertek egyet. Minden programnal fontos az attekinthetoseg,
> de ez nem lenne szabad, hogy a hatekonysag rovasara menjen.
Ellenpelda: lasd Objektum Orientalt programozasi szemlelet. Atekinthetobb
mint a hasonlo funkcionalis megoldas, viszont joval szovodmenyesebb a
generalt kod.
> Attekinthetoseget lehet novelni jo valtozo es fuggveny-elnevezesekkel, szep
> tabulalassal, jo dokumentacioval, nagyon sok mindennel, ami nem szabad, hogy
> a hatekonysagot befolyasolja. De ez messzire vezet, ebbe ne menjunk bele...
En nem erre gondoltam! Nem a vizualis attekintesre, hanem arra, hogy ki
tudod bogozni hogy mit csinal az algoritmus. Ugyanazt a feladatot meg lehet
csinalni bizonyos dolgok ismereteben erosen kioptimalizalva, hackelve, meg
altalanosan, a feladatkiirashoz illeszkedoen. Az utobbit mindenki megerti,
de lehet hogy sokkal lassabb mint az elozo. Ezt viszont lehet hogy csak az
erti aki irta.
> Ez igaz, de hol van ennek koze az attekinthetoseghez? Mas algoritmust
> hasznalsz, mashogy osztod el a funkciokat, stb.
Nem ahhoz, hanem a hatekonysaghoz irtam. Ha tudod hogy pl. a PIC-en idiota a
memoria arch, akkor ugy erdemes pointerekkel operalni, hogy ezt tudomasul
veszed, mert lehet hogy irdatlan kod lesz belole. Nem lehet a RAM/ROM
pointereket osszekeverni, es hatekonyan jatszani veluk, mint pl. PC-n.
> Egy altalanos pointer muvelet, lehet. De ha a fordito nem ismer fel egy
> konstans-pointert es nem general jo kodot a vele torteno muveletekre, akkor
> vacak a fordito.
Nem csak const ptr van... Meg ezermilio fele muveletet lehet a pointerekkel
is csinalni, csak ha a hw korlatozza a lehetosegeket...
> Megintcsak: miert kell ehhez speci tipus? Raadasul meg a leirasban is benne
> van, hogy az utasitasnak lehetnek fura mellekhatasai, ezert 'esszel' kell
> alkalmazni. Pont errol beszelek: a magasszintu nyelvben nem irod le
> egyertelmuen a forditonak, hogy mit szeretnel (a nem specifikalt bit-ek
> kezeleset illetoen) azaz a fordito (ez esetben CPU) belatasara bizod a
> dolgot. Ha viszont elorinad pontosan a teendoket, akkor a fordito is
> pontosan tudna, hogy mikor *legalis* a speci CPU utasitas hasznalata, es
> mikor nem.
Belegabalyodtal sajat allitasodba. A vita targya (static bit) konkretan
leirja mit akarsz. Ha x|=40-et irsz, az nem. Ha nem optimalizal a fordito,
akkor lehet hogy OR muveletet fordit, ha meg igen, akkor lehet hogy bit
utasitast.
>>Vagy, pl. ha kell egy szam 0.0-10.0 kozott, akkor float tipussal tok
>>kenyelmesen megoldhato, jo nagy kodot fog generalni. Erdemes elgondolkodni
>
> Persze, de hogy jon ez ide? Amugy meg, most te is az en szekeremet tolod:
> nem bizod ra a forditora, hogy a float-jaidat fix-pontos tort-kent
> ertelmezze. Kezzel szepen leirod, hogy mit szeretnel, de azt elvarod a
> forditotol, hogy amit specifikaltal, azt optimalisan valositsa meg. Es itt
> sem az a megoldas, hogy a fordito bevezet meg egy uj tipust, hanem az, hogy
> felismeri es optimalisan valositja meg az altalad eloirt muveleteket.
Es ezert felulbiralja hogy en float-ot deklaraltam? Ez mar inkabb
nem-szabvanyos... A float az float, es generaljon hozza float kodot. Ha
nekem nem tetszik nem hasznalom, de csinalja igy.
> Nagyon sok esetben nem erdemes sebessegre optimalizalni. Pontosabban, a
Szerintem meg altalaban sebessegre erdemes optimalizalni, csak ott nem ahol
a kodmeret szamit.
> sebessegre optimalizalas nem sokban kulonbozik a kod-meretre valo
> optimalizalastol. Egy-ket olyan dolog van, amit nem csinalnak meg meretre
> optimalizalas eseten, es par optimalizalast maskent hangolnak, de alapvetoen
> ugyanaz a ketto. BTW: egy P-VI-esen is gyorsabb tud lenni a kisebb kod, mert
> kevesebb cache-miss-t okoz, pl. Nem csak kis mikrokontrollerekre igaz, amit
> irsz.
Nem is irtam hogy _csak_, hanem azt irtam hogy PIC-en igy van. PC gyorsabb
tud lenni, meg lassabb is. Ott nem trivialis, mert lehet hogy van olyan
utasitas amit pipeline modon vegre tud hajtani egy masikkal egyidoben, meg
van olyan is, amit nem, es mondjuk 42 ciklusba telik.
--
((( Móczik Gábor )))--((( hu <- DOT <- freemail <- AT <- progzmaster )))
((( Debian unstable )))-((( Kernel 2.4.20 )))-((( Celeron466 / 128Mb )))
((( --> Vigyázat! Ön súlyos közlekedési balesetet szenvedett. <-- )))
((( --> Kívánja, hogy a légzsák felfúvódjon? <-- )))
More information about the Elektro
mailing list