PIC vs ATMEL #2

[VF]

Thus spake Nagy Endre <gumo at lucifer.kgt.bme.hu>:

> Ezt most hiszed, vagy tudod? Kiprobaltad?

Nem kell kiprobalni, egyertelmu.

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

Le is kodoltak, mint emlitettem, tobben is probalkoztak vele. Csak
valahol becsuszott 1 hiba, es sohasem sikerult megtalalni.
Mellesleg en valoszinunek tartom, hogy a Z80-ra kezzel optimalizalt
asm meg mas procin is gyorsabban fut (atlagosan ~1.5 AVR utasitas kell
egy Z80 utasitas emulaciojahoz, 8051-en kb 5 utasitas kellett)
mint ha C-ben irtak 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.

Latod hogy nem :) En mar a masodik-harmadik fejlesztot valtom le,
aki ezzel foglalkozott... Van tobb ezer eladott termek is, melyen
cross-compilerrel fut az eredeti algoritmus, hibatlanul.
De ezt a reszet lehet hogy tenyleg jobb lett volna c-ben, ugyanis
alapesetben nem lett volna kotelezo a real time, az mar az en
talalmanyom, ha meg lehet csinalni, miert ne.

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

Van ott meg mas is, pl infra kommunikacio, AD mukodtetes, grafikus
lcd kezeles, hanggeneralas PWM-el mexakitasbol, stb... Ezeket mindet
asm-ben kell megirni, nem tudom mit lehetne C-ben...
Foleg hogy a mexakitasok nem mentik el memoriaba a regisztereket,
hanem le van foglalva nehany amit a foprogram nem hasznal, a nagyobb
sebesseg erdekeben. Ezt hogy lehetne megcsinalni C-bol?
(Ez komolyan erdekel, van megoldas?)

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

Termeszetesen, a minosegi termek eloallitasahoz tapasztalt fejleszto
kell. Szart akarki tud csinalni.

>> A 8 bites procikra mind nagyon rosszul forditanak.
> 
> Szerintem egyaltalan nem.

Szerintem meg igen :) De talan nezz bele a kodba. Valoszinuleg meg
nem tettetek meg, akkor nem irogatnatok ilyeneket... Ismetlem, ez
nem 32 bites proci. En a mult heten eleg sokat turtam a kodot,
irtam is a listara, ki akartam deriteni hogy hogyan adhatok at
parametereket asm-bol egy C fuggvenynek. Bonyolult, logikatlan,
ertelmetlen kodot csinal, ide-oda mozgatja a regisztereket feleslegesen.

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

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

> 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

Egesz jo, de az enyem jobb :)
Nem tudom megmerni hany ciklus, mert a __mulsi3 fuggveny nincs meg.
Mas kerdes, hogy a szuro fociklusaban egyaltalan miert van rcall,
a hozza tartozo ret-tel egyutt 7..9 ciklus, meg tobb ha esetleg kulso
memoriaban lenne a stack.
(osszehasonlitaskent nekem a 32 bites elojeles MAC 21 ciklus)
Mashogy csinalja az elojel korrigalast, nehany ciklussal tobb,
es nem is ertem pontosan, mindegy.
Nem hasznal konstans 0 regisztert, azzal is sok ciklust meg lehet
takaritani.
Kene latni a __mulsi3 fuggvenyt. Veletlenul nincs tele push/pop-pal?
Ha geci akarnek lenni, abba kotnek bele, hogy ez igy egyaltalan
nem is mukodik, mert rosszul skalazod az egyutthatokat.
Nem csak az erosites cseszodik el, mert IIR, a rossz ertek vissza
van csatolva, megbolondul az egesz.

De valoban nem rossz, nem gondoltam hogy ilyen ugyesen hasznalja a
mul-t. Ugyanis lebegopontos szamitasokhoz sem a GCC, sem az IAR
nem hasznalja egyaltalan, bitenkent szoroz...
Sajna olyan asm progim nincs, amivel ossze tudnank hasonlitani.
(De lehet hogy hamarosan lesz)

> Gumo

-- 
Valenta Ferenc <vf at elte.hu>   Visit me at http://ludens.elte.h u/~vf/
"A lamerek egyik fo ismertetojele, hogy maniakusan felnek a virusoktol"