[elektro] PIC kezdés

Ágó István ago.istvan at gmail.com
Mon Jun 9 10:46:29 CEST 2008


Véletlen elküldtem az előzőt.

Szóval:
Azzal én is egyetértek, hogy a hiánya nem nagy veszteség. Sőt, az így
optimalizált kódot lehetetlen debuggolni forráskód szinten, mivel
ugyanahhoz az asm kódrészlethez több C kódrészlet is tartozhat.
Fejlesztés idejére tehát érdemes kikapcsolva tartani, és esetleg csak
a végső termékhez bekapcsolni, ha úgy belefér a kód egy kisebb
programmemóriával rendelkező, de egyébként ugyanolyan chipbe (pl.
18F2455/2550).

2008/6/9 Ágó István <ago.istvan at gmail.com>:
> Úgy emlékszem, úgy készíti el a szubrutint, hogy ne kelljen
> regisztereket menteni. Sebesség terén nem javít, az biztos (bár ha
> optimális kód kell, akkor eleve nem C-ben kell nekiesni, legalább a
> kritikus részt asm-ben megírni hozzá).
>
> Azért a béna programozót úgy nézd, hogy akár egy tömbből történő
> adatkiszedés vagy tömbbe beírás is lehet 10-20 utasítás, ha valami
> alapján ki kell számolni az indexet. Ez akár egy sor is lehet a C
> kódban (amit esetleg makróval old meg a programozó). A Procedural
> Abstraction gyakorlatilag a makrókat irtja ki, csak tud keresni
> sajátmagának is "makrókat", nemcsak azokat szedi ki, amiket  a
> programozó készített.
>
> Azzal én is egyetértek, hogy a hiánya nem nagy veszteség. Sőt, az íNem
> szokás nagyon kicentizni a programmemóriát, hogy szükséges lenne a
> (valamivel) kisebb kód.
>
> 2008/6/9 István <hobilobi at gmail.com>:
>> A Procedural Abstraction azt csinálja, hogy ha
>>> több helyre írtad ugyanazt a kódrészletet, akkor abból szubrutint
>>> csinál, és csak egyszer építi be a programmemóriába, majd több helyről
>>> meghívja. Tehát helyet takarít meg.
>>
>>
>> Néhány  utasítás esetén ez túl sokat nem spórol, mert ugye meg is kell hívni. Időben rosszabb
>> is lehet, mert a rutinban esetleg menteni kell regisztereket.
>> Ha viszont több utasításra (monjuk 10-20 felett) talál ilyeneket, akkor elég béna az a
>> programozó aki az ilyen nem veszi észre. Szóval szerintem szinte semmi hátrányt sem jelent, ha
>> ez nem működik.
>>
>>
>>
>> --
>> Szabados István
>>
>> -----------------------------------------
>>          elektro[-flame|-etc]
>>
>


More information about the Elektro mailing list