PIC vs ATMEL #2

[Nagy Endre]

> > A problema ott van, hogy asm-ben irtak eredetileg. Ha C-ben irtak volna,
> > most nem kellene atirni.
>
> Az biztos, mert nem is lett volna termek az elozo verziobol sohasem.
> A 80C552 verzio 16 masodpercig gyujtott adatot (szabvany) kb 10 masodpercig
> analizal. C-ben percek lennenek, de valoszinu hogy bele sem fert volna a

Ezt most hiszed, vagy tudod? Kiprobaltad?

> Kuldhetek mintat. Kivaloan dokumentalva van. (Mibol gondoltad hogy nincs???)

Ha kivaloan dokumentalva lenne (nem az asm forras, hanem maga a program),
akkor egy kezdo C programozo is lekodolhatta volna.

> Ennek ellenere nem sikerult meg senkinek. Ismetlem, tobb 10000 sor.

Asm-ben igen. C-ben mennyi lenne, ha nem asm-bol kene atirni?
Ekkora projectet asm-ben irni azt ugy hivjak, hogy biztositott munkahely.

> Mas esetekben is hasznos az asm. Tudom, a ledvillogtatot is sokan
> valami embedded linuxos kartyaval csinalnak... Jo dragan.

Tulzol, ilyet senki nem mondott. Epp arrol beszelunk, hogy a C kozel
optimalis asm-et general, nem pedig embedded linuxot.

> > Hogy rovid, szemleletes es hordozhato legyen. Egyebkent ha eletbevago egy
> > adott asm felhasznalasa, beteheted egy file-ba, a linker majd elintezi. Vagy
> > beteheted egy libbe is.
>
> En inkabb forditva probaltam, asm-bol akartam C-t hivni.
> Nem mukodik, bar meg lehetne oldani ha nagyon kene...

Megoldhato, de minek? C-be szokas asm betetet tenni olyan helyeken, ahol
az elengedhetetlen. Ha az IIR szurodnel par utasitas kulonbseg mar
halalos, akkor beteheted asm-be.

> Valoban, 32 bites procikra neha egesz jol optimalizal.
> Azert a kezi optimalizaciot nem tudja utolerni.

Neha meg azt is.

> Es amig nem talaljak fel a mesterseges intelligenciaval mukodo
> forditokat, erre nincs is semmi esely.

Persze, sokkal jobban kene ismerni a forditonak a programozo szandekat, de
egyreszt ezt a forditoval lehet sejtetni, masreszt nagyon durva
heurisztikak vannak. Pl. egy integer 8-cal osztasa szo nelkul shiftelesse
optimalizalodik, ahogy asm-ben is tennenk. Vagy pl. felcserelodik a
kulso-belso ciklus, ha ugy tobb cache hitet general. Ehhez asm-ben mar
tapasztalt programozo kene.

> A 8 bites procikra mind nagyon rosszul forditanak.

Szerintem egyaltalan nem.

> Irtam is a listara, probaltam kideriteni hogy hogyan kell atadni a
> parametereket a C fuggvenynek ha asm-bol hivom. Meglepo modon ez az
> optimalizacio szintjetol is fugg. (ha kikapcsolom az optimalizaciot,
> regiszterben varja, ha bekapcsolom, a memoriaban, erdekes...)

Vannak ezt szabalyozo parameterei is a forditonak.

> A generalt kodot barmikor erolkodes nelkul megverem, ennel mindig sokkal
> jobbat szoktam irni.

Sokkal jobbat szerintem nem lehet.

> De ha mar annyira jonak tartod a C forditokat, irj legyszives egy 24 bites
> koefficiensekkel es nodeokkal es 48 bites akkumulatorral dolgozo masodrendu
> IIR savzaro szurot, es hasonlitsuk ossze a teljesitmenyet az asm
> verzioval. De akar lehet 16/32 bites is, az elso verziom nekem is olyan
> volt, nem akarlak nagyon mexivatni a 24 bittel, mert mire azt C-ben
> lekodolod, en 3x megirom assemblyben.

A pontos korulmenyeit a dolognak nem reszletezted, de legyen:
http://www.kgt.bme.hu/nagye/iir/

Megjegyzesek: a fordito hivasi kornyezet hijan nem tudott tokeletesen
optimalizalni. Pontosabban tudott, csak akkor eldobta az egesz nem
hasznalt algoritmust, ezert a ki- es bemenetet le kellett horgonyoznom a
memoriaba static modositoval. Konkret kornyezetben lehetne
regiszterekben. Magat az algoritmust a main()-be irtam, mert amig
konkretan nem hasznaljak fuggvenykent, addig referencia hijan a gcc nem
tudja inline-ositani, es a legrosszabb esetre keszul, minden regisztert
ment. A __ kezdetu hivasok a libc-be mutatnak, ami tobbnyire az atmel
appnotes-on alapul, pl. 32 bites elojeles szorzas.

Tettem bele debug infot (hogy ronda legyen :), de a lenyeg a prologue utan
van.

Kivancsi vagyok, hogy hasonlo korulmenyek kozt tenyleg raversz-e sokszaz
szazalekot asm-ben, akar meretre, akar futasidore.

> Teljesen termeszetes, hogy az algoritmus bizonyos reszei tobb procira
> meg vannak irva, es a masik forrast forditva 30% teljesitmeny novekedes
> illetve csokkenes merheto! Mind a ketto C forras. Latatlanban is biztos

Elofordul. Sejtetni lehet a C forditoval, hogy mit varunk tole.

> vagyok benne, hogy asm-be atirva meg nagyobb teljesitmeny lenne elerheto.

Marginalis novekedes talan lenne.

> Es ha mar amugy is minden procira mas C forras kell, nem sok ertelme van...

De, hogy azonnal mukodik masutt is, legfeljebb 30%-kal lassabban. Nem
ennyin szokott mulni egy project. Ha meg ennyin, akkor nem kesz modulokbol
lapatoljuk ossze, hanem odafigyelunk ra.

> Ha a forditok valoban olyan jo kodot tudnanak generalni, hogy azon
> lenyegesen mar nem lehetne optimalizalni, akkor en is magasszintu
> nyelvben programoznek mindig...

Mit ertunk lenyegesen alatt? 10s helyett tobb perc az oke, de ilyet a C
nem tesz.

> A valodi sebessegeket pedig azonnal osszehasonlitjuk, amint kesz a C-ben
> irt szurod. En sajnos nem fogom tudni futtatni, mert a C verzio biztos nem
> lesz kesz a szuro idoablakaban, de majd valami JTAG emulatorral :) kimerjuk.

Hat jo, merd, hasonlitsd...

> Aggaszto hogy ilyen tevhitek terjednek a listan, egyesek mar nem is
> tudjak hogy egyaltalan mi az hogy assembler...

Milyen tevhitek? Hogy egy jo C fordito egy jo asm programozoval vetekszik?

> > Effele kompromisszumok nelkul is hasznalhatnal hordozhatobb, tomorebb
> > programnyelvet.
>
> Ez mar egy altalanosabb, igy nehezebben cafolhato kijelentes :)
> Pontosan milyen nyelvre gondoltal?

A p-code-hoz kozeli nyelvek pl. eleg hatekonyak minden korrekt stack-kel
rendelkezo procin.

> Itt jegyeznem meg, hogy az AVR procik furcsasagai es kellemetlen
> meglepetesei, ha ugyanarra gondolunk, mind egy-egy nehany soros
> makroval egyszeruen es tokeletesen eltuntethetok...
> (Erdekes hogy erre csak en jottem ra)

Erdekes, hogy mekkora onbizalmad van...

Na megyek, melo van.

Gumo