PIC vs ATMEL #2

[VF]

Thus spake Füzesi Arnold <arno at freemail.hu>:

> Mar megint bekepzeltel valamit. En nem kiserleteztem semmit, amibol arra a
> kov-re jutottam volna, hogy
> az ABEL jobb kodot fordit. Te magyarazod ezt is mindenfele alap nelkul...

Szo sincs arrol hogy jobbat fordit. Ugyanolyan szar. Amig kezzel meg
nem optimalizalod... (Meg mindig nem jott at amit privatban leveleztunk...)
Sohasem mondtam ilyet!!! Nem kene kiforgatni a szavaim...

>> programozza, sot ahhoz is az appnote-k jelentos resze asm progit javasol.
> 
> Kb ez az egyetlen proci amivel leallnek asm-ben.
> Pusztan azert, mert szep az asm-je..Meg tetszik a hardveres deadtime nelkuli
> cikluskezeles.

Aha. Szerintem meg szep tovabba az m68k, Coldfire, SH, AVR nyelve is.
Izles kerdese... Az x86 es PIC nem szep, arra nem progizok asm-ben,
ha nem muszaj...

>> Tudod, mernokok a vilagban...
> 
> Igen? Hallgatlak..
> Tudod a mernokok a vilagban nem azzal ervelnek, hogy az atmega appnote-okban
> is
> asm-ben vannak a dolgok. Ez eleg gyengyusz....

Akkor megegyszer: az az asm megverte a C forditot.
Es csak azert nem jobban, mert nem 24 bitesen szamol. Ugyanis en 24
bittel szamolok. Na azt hogy csinalod meg C-ben? A fordito nem fogja
tudni elohuzni az Atmel appnote szerinti, termeszetesen asm-ben irt,
sebessegre optimalizalt 24 bites szorzast, mert nincs 24 bites tipusa,
es nincsenek 24 bites konyvtari fuggvenyei. Meg kell irni minden nullarol,
ugyanannyi melo mint asm-ben, csak messze nem lesz olyan jo!!!
32 bites procin nem gond, 0..32 bites muveleteket ugyanannyi ido alatt
csinal meg. Ha 40 bit kell, csinalsz 64 bites rutinokat, gyorsabb mint
a 40 bites. 96 bitnel fordul a kocka, ha a C-nel 128 bit jon, es asm-ben
kenyelmesen meg tudod irni a 96 bitest. De ilyen pontossag nagyon ritkan
kell, tehat a C altalaban jo.
8 bites procin a 24 bites szorzas kb fele (vagy lehet hogy kevesebb?)
annyi ido mint a 32 bites, az osszeadasok 75% ideig tartanak.
(24 bithez 9db 8 bites szorzas kell, elojelet 2 helyen kell 2 digiten
gorgetni, 4 helyen 1 digiten. 32 biten 16db szorzas, tobb es hosszabb
osszeadas +rengeteg elojel gorgetes akar 3 digiten keresztul)
C-ben meg kell irni a 24 bites tipusokat, es azokra az osszeadast,
szorzast. Optimalizalt konyvtari fuggvenyek, amit egy 9 ciklusos rjmp-vel
meghivhatna :) nincsenek, mindent a forditonak kell optimalizalnia.
Az pedig, amint lathattuk, nem dolgozik olyan nagyon jol...

Sot lehet hogy a legjobb lett volna 15 bites koefficiensekkel szamolni,
csak a nodeokat tarolni 24 biten. Nem probaltam ki. Azt hogy csinalod
C-ben? Es akkor meg lehet optimalizalni az egesz szam erteku egyutthatokat,
lehet gyorsitani a szorzast a 0 erteku bajtok vizsgalataval, stb...
Tudom hogy okosak a forditok, de ennyire nem.

> a kozlekedesi lampak kodjat, a belepteto rendszerek kodjat, es stb.
> Csodalkozva fedezd fel, hogy szinte mindet C fordito generalta.
> Majd vond le a kovetkeztetest, tanulj belole.

Es az algoritmusok fociklusait mindenhol asm-ben irtak. Tanulj belole!
Ezek olyan dolgok, amiket nem lehet sokfelekeppen megirni. Aki mashogy
csinalja, az lemarad. Pl Atmel appnote-ban a szorzasra 2 fele megoldas
van, a gyorsabb egyetlen ciklussal gyorsabb mint a lassabb, viszont
2 regiszterrel tobbet hasznal. Ennel jobban nem lehet megcsinalni.
(Hiaba akarmilyen ugyes a fordito, az optimalis megoldas eleve ismert,
gyarto honlapjarol letoltheto, annal jobb nincs es nem is lesz soha!!!)
A GCC siman kitalalt egy harmadik, jo nehany ciklussal lassabb megoldast..
Kepzeld el, hogy minel nagyobb sebesseg kell. Az egyik a proci teljes
kihasznalasaval 30 kilobajtot dolgoz fel masodpercenkent, a masik 40-et.
Ha pedig adott a szukseges sebesseg, akkor a feldolgozas minosegen lehet
javitani, a proci teljes kihasznaltsagaig. Magyarul ugyanolyan koltsegbol
jobbat lehet kihozni. Addig optimalizalok, amig az elsorendu helyett masod
vagy magasabb rendu szurot hasznalhatok, vagy ket kulonbozo fajtat egymas
utan. Stb... Ha mar tokeletes a feldolgozas, csokkenthetem a fogyasztast.
Plusz 1 ora keszenlet milyen jol jon, ha emiatt pont vegig tud csinalni
egy napot, nem kell napkozben tolteni/elemet cserelni. Vagy egy ezressel
olcsobban tudjuk adni/nagyobb rajta a hasznunk. Emiatt arban jobbak vagyunk
a kunkorrencianal, vagy evi nehany mila plusz bevetel.

A felevente megjeleno, bugos szoftveru telefonok nem erdekelnek!
A legujabb nokia mar keket is tud halni, kulon le tudnak akadni benne a
processzek, szep kis ablakocska kozli, hogy most eppen a GSM alrendszer
halt ki, inditsd ujra a telod. Szep uj vilag. Mi mashogy dolgozunk,
nem jon ki felevente uj termekunk, nem vagyunk rakenyszeritve hogy
szart csinaljunk. Viszont ahhoz eleg sokat adunk el, es eddig ezt a
termeket meg csak itthon, hogy megerje ilyenekkel foglalkozni.

> Hat en nem csak szorakoztam, hanem irtam ra pl szoftveres PLL-t.
> Marmint egy ADSP2181-re.
> Kepzeld, asm-ben.... :)
> De amint egy DAB-ot kell lekodolni nem asm-ben fogok szenvedni...

Gratulalok. En meg CF + smartcard kezelest C-ben.
Es akkor mi van? Mivel asm-et is hasznalok, 8 bites procin biztos hogy
lenyegesen hatekonyabb progikat tudok irni.
Ugyanakkor a C-t is tudom hasznalni. Nem vagyok profi benne, ez nem
ketseges, mindig itt van a gep mellett a programozzunk C nyelven vagy
mi cimu konyv.

> Arnold

-- 
Valenta Ferenc <vf at elte.hu>   Visit me at http://ludens.elte.h u/~vf/
"Legszebb orom a karorom, mert nincs benne irigyseg."