PIC vs ATMEL #2

[Füzesi Arnold]

----- Original Message ----- 
From: "VF" <vf at elte.hu>
To: <elektro at tesla.hu>
Sent: Wednesday, February 11, 2004 7:33 PM
Subject: Re: PIC vs ATMEL #2


> sebesseg erdekeben. Ezt hogy lehetne megcsinalni C-bol?

Meglehet.

> parametereket asm-bol egy C fuggvenynek. Bonyolult, logikatlan,
> ertelmetlen kodot csinal, ide-oda mozgatja a regisztereket feleslegesen.

Hozzaertes kerdese.
Ha az asm-et meghivod, akkor ugye a hivo foglal memoriat.
Vagy a regisztereken, vagy a stack-en.
Tobbit radbizom. Minden benne van a doksiban.Illetve a C konyvekben...

> Pl? Az IAR-nek nincs. A doksiban azt irjak, hogy az r17:r16-ban
> kell megadni, ha csak egy parameter van, de az 'optimalizacio' ezt
> atteszi a memoriaba. Kerdes, hogy minek. Optimalizacio nelkul csak
> regiszterekben elfer minden, nem ertem miert jo hogy a ketszer
> lassabb memoriaba kiteszi...

Azert mert parameteratadas ket esetben van.

Belepes

    Kozben ezerrel altalaban "auto" tarolasi osztalyu valtozok
irodnak-olvasodnak.
    Amit ugye celszeru registerben tarolni.
    Ezert a fordito nagyon kedvesen nem pazarolja el a registereket.
    De ha kered (optimalizacio) akkor "elpazarolja"
    Ha kered, akkor a fuggveny valtozokat mindenkeppen registerben tarolja.
    Register tarolasi osztaly.
    Ha kered, akkor fenntart registereket (adott szamut) ilyen celokra.

Kilepes

De ha mondjuk pointert adsz at, es nem adatot, talan az a legjobb sok
esetben.

> mul-t. Ugyanis lebegopontos szamitasokhoz sem a GCC, sem az IAR
> nem hasznalja egyaltalan, bitenkent szoroz...

Ott van a __mult() stb. intristrict fuggveny.
Az a hw-t hasznalja.
Akinek nem tetszik a sw-es szorzas olyat ir amilyet akar ezeket
felhasznalva.
Valszeg ezert nem irtak meg.
Mert akinek ennyire szamit a sebesseg valszeg spec adatokkal dolgozik, és
nagyonnagyon optimalis
kodot tud irni arra a spec esetre az emlitett fuggvenyekkel.

Nem olyan rossz ez a C, csakhat erteni kell hozza, meg felfogni, hogy a
sw-es optimalizalas nem tudja potolni
a lexikalis tudast, a rendes sw tervezest, stb.
Illetve azt, hogy a C-nek nem az az alap filozofiaja, hogy uberallesz gyors
legyen.
Rendesen strukturalt programokat lehessen irni.
Mindemellett rettenetesen gyors. Kozel ASM sebessegu, de  igen magas szinten
is lehet programozni benne.
Marmar BASIC, OOP "light" szinten. Ez tesz naggyá. Ezert nincs sok
letjogosultsaga a tobbi nyelvnek mellette. Foleg mert ASM betetet barmikor
es barhol be lehet szurni, ha szukseges.
Tehat innentol az ASM-nek sem sok.
(Program motorja asm, a user interface meg C. Tipikus eset, lazan
megcsinalhato bermelyik C forditoval)

Pl for ciklust erdemesebb visszafele szamoltatni gagyibb uC-eken (ahol cmp
utasitas nuku), tomb helyett pointert
hasznalni stb stb stb stb stb stb stb stb....
Ezeket sajna meg kell tanulni.
El kell olvasni a compiler beallitasokat, es felfogni.
Hogy lehet __nosave interrupt-ot csinalni stb.

ASM-hez ez nem kell.
Ott leul az ember, es kodol.  (Programoztam ASM-ben eleget. Nagyon jo erzes
amikor az ember egy problemat
elegansan megold, orul maganak. Ismerem az erzest, marha jo, elismerem.De
elmegy az ideje cefetul vele...Es en nem tudok atlatni tobb 10e sor asm
kodot. Meg megirni sem. Elkopna szo szerint a bill.
Kb ennyi lenne az amiket mostanaban csinalok. C-ben is tobbezer...)



Arnold