C absolut cimu valtozo generalasa

[Andras Tantos]

Hali!

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

Viszont meg lehet csinalni nelkule is, raadasul a fordito ugyanazt a kodot
generalja (szerinted legalabbis) -> felesleges.

Mar igy is eleg sokan szidjak a C/C++-t azert, mert azonos dolgokat sokfele
keppen lehet leirni. Miert kell ezeket az eseteket meg tovabb szaporitani?

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

A deklarico hibaja csupan annyi, hogy nem explicit benne, hogy lehetnek
kellemetlen mellekhatasai. Leven a valtozoid kulon vannak delkaralva a
forraskod olvasasa soran nem egyertelmu, hogy egy valtozo modositasa hathat
mas valtozok ertekeire is. Ha mindent byte-nak (unsigned char-nak)
deklaralasz, es kiirod a bit-muveleteket, akkor ezek a mellekhatasok
explicit benne vannak a kodban, es raadasul az egymasra potencialisan
hatassal levo muveletek szukseg szeruen egy helyen vannak definialva. A
lenyege a mondandomnak: bit-muveletekkel pontosan eloirod a forditonak, hogy
mit akarsz a tobbi bittel csinalni (olvass, valtoztass/ne valtoztass, irj).
Bit-valtozoval nem definialod a viselkedest, sot meg csak nem is a
forditora, hanem a CPU-ra bizod a dontest.

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

Lehet, hogy valoban nem eleg jo a pelda. De azt hiszem a szabvany nem
rogziti a kiertekelesi sorrendet, azaz, az, hogy mikor dolt el a feltetel
eredmenye, nem feltetlenul egyertelmu. De minegy is, itt egyet ertunk: a
forras kodnak egyertelmuen specifiaklnia kell a viselkedest. Szerintem a
bit-valtozok ezt nem teszik: nem specifikaljak, hogy mi a teendo azokkal a
bit-valtozokkal, amiket nem modositasz, viszont mellekhataskent
modosulhatnak.

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

Persze, persze. Ez a kod mindket esetben hulyeseg, csak az egyik esetben
konnyebb a hibat megtalalni. A javitas is konnyebb lesz. (Az en megoldasi
javaslatom egy csomo makro definialasa, amik kezelik az egyes bitek
allitasat/torleset, es ezekben a makrok-ban lennenek a bit-muveletek
eldugva. A makrok modositasaval kozpontilag lehet arnyek-regisztereket, vagy
barmi mast hasznalni, amivel a problema orvosolhato.)

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

Ez kb. ugyanaz, amit en leirtam: amig elfer egy int-ben (azaz a CPU 'nativ'
tipusaban) addig oda kell rakni. De a sorrendre nezve semmi kikotes nincs.
(Vagy van? Van valakinel kezeugyeben egy C szabvany?)

> A sorrend meg szerintem architektura fuggo. Ha nem fejlesztesz ilyen
> torzszulott processzorra amin lehet valtani a sorrendet, akkor szerintem
> hasznalhato.

Nem ez a mondokam lenyege, hanem ez: nem difinalod pontosan a viselkedest,
de a program mukodese fugg a viselkedestol. Azaz a
fordito/kornyezet/processzor/architektura kenye-kedvere bizod az eredmenyt.
Ez nem helyes. Egyebkent szerintem a sorrend fordito fuggo, de ez mellekes.

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

Ez bizonyos esetekben igaz, masokban nem. De itt mar programnyelvet valtasz
(C->C++ pl.) arrol meg eddig nem volt szo.

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

Tobbe-kevesbe egyet ertek. Sajat tapasztalatom az, hogy lehet attekintheto,
optimalis kodot irni, csak *nagyon* nehez. De hosszu tavon megeri
belefektetni az energiat - felteve, hogy nem eldobhato project-rol van szo,
hanem olyanrol, amit hosszu evekig koszorulgetsz, fejelsztgetsz, javtigatsz.

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

OK. Ilyen esetben valoban van ertelme architektura-specifikus megoldasoknak.
(Az en peldam DSP procik kettos RAM memoriaja lett volna. A valtozok
megfelelo elrendezese a ket memoriaban akar ketszeresere is gyorsithatja a
programot.) De nem tudom, hogy az eredeti szintaxis mennyire tamogatja
ezeknek a problemaknak a megoldasat. Ha a '@' utan csak cim szerepelhet (cim
tartomany nem), akkor nem igen jo erre. Amugy meg, ha mar ilyesmit csinal
egy fordito, nem erdemesebb, valami legalabb reszben szabvanyos megoldast
hasznalni: #pragma, __attribute__, stb.?

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

Persze, de nem is errol beszeltem. A konkret problemanal maradva: egy
valtozo pontos cimhez kotese forraskodbol C-ben felesleges, mert konstans
pointer-rel a problema megoldhato, meg a hasznalati szintaxis sem valtozik.
Ha meg a fordito nem ismeri fel ezt a helyzetet, akkor vacak. Vegul, ha mar
valamit csinalunk a forditoval (mi, fordito fejlesztok ;-)), hogy az eredeti
problemat (pontos cim elerese C-bol) megoldjuk, inkabb ismertessuk fel vele
a konstans-pointer hivatkozast, mint vezessunk be specialis szintaxist.
Mellesleg a konstans-pointerek felismerese nem csak ebben az esetben jo, sok
mas esetben is hasznat veheti a fordito (pl. sztring-kezeles, tomb-kezeles),
mig ennek a speci szintaxisnak semmi mas esetben nem latja hasznat.

> Belegabalyodtal sajat allitasodba. A vita targya (static bit) konkretan
> leirja mit akarsz. Ha x|=40-et irsz, az nem.

Pont forditva. A bit-valtozo nem ir elo semmit a tobbi bitre vonatkozoan,
mig az x|=0x40 az egesz byte-ra nezve ir elo viselkedest.

> > Nagyon sok esetben nem erdemes sebessegre optimalizalni. Pontosabban, a
> Szerintem meg altalaban sebessegre erdemes optimalizalni, csak ott nem
ahol
> a kodmeret szamit.

Ebbe ne menjunk bele, messzire vezet. A mondandom lenyege: sebesegre es
memoriara optimalizalni nem is annyira mas, mint elsore lattszik talan. De
az eredeti tema nem ez volt, ugyhogy ezt hagyjuk.

Udv,
Tantos Andras