lattam nem sokan gondolkodtak asm-ben :( 

az biztos, hogy macro-kent erdemes ezeket a rutinok hasznalni, mivel
tobb ido lenne a rutin be/ki lepes, mint maga a rutin :)

itt az en rutinom:
kicsi, nem hasznal dx-et, de nem gyorsabb :(
akkor jobb, ha bekerul a masik rutin elo es moge push/pop dx, vagy
barmi, a dx hasznalata miatt

               orajelek P5   486
 or ax,ax               1     1  <--ez nem kell ha ax-et elobb szamoltuk
 lahf                   2     3     ki egy aritmetikai utasitassal, ami
 sar ax,14              1     2     beallitja SF,ZF-et ax szerint
 xor ax,1               1     1  
                oszesen 5     7

lehet, hogy utoljara xor al,1 is jo, de felek a penalty-tol, ha egybol
felhasznaljuk ax-et (bizonytalan vagyok a byte es word valtakozo
hasznalatkori plusz ciklusban, meg kell merni adott esetben, adott
CPU-n)
a gond az lahf lassusaga, es ezt valoszinu nem fogjak optimalizalni a
CPU gyartok ...

elv: 
or ax,ax -> SF ZF beallitodik
SF ZF  elvart kimenet
 0 1 -> 0  
 0 0 -> 1
 1 0 -> -1
(1 1 ilyen nincs)
tehat ZF-et negalni kell, SF-et meg vegig huzni a felsobiteken,
szerencsere ZF, pont SF alatt van, SF meg pont ax MSB-je.

Marosi Istvan rutinja (nem kell xor dx,dx -> sbb dx,dx megcsinalja)
 cmp ax,1               1     1 
 sbb dx,dx              1     1     
 sar ax,16              1u    2
 inc dx                  v    1
 or ax,dx               1     1
              osszesen  4     6 
Bye
-- 
Picard / Hydrogen       
Kovacs Gabor     mailto:
tel:(30)606169   (1)2513817

Sziasztok Coderek!

Eloszor is elnezest, hogy megint nem igazi, verbeli coder problemaval
zargatlak Benneteket, de nagyon erdekel a velemenyetek!

Szoval MFC C++ vagy WinApi C?
A dolog elso resze: C vagy C++. Ugye C-ben az ember strukturaltan
programozik, es ugy istenigazabol igyekszik kihasznalni a nyelv adta
lehetosegeket, es az eredmeny tobbnyire (a developer ugyessegehez
kepest) tomor, gyors, hatekony futtathato kod. De esetleg konnyebb
belezavarodni, nehezebb dokumentalni, macerasabb tovabbfejleszteni.
C++-ban jobban bele vagyunk kenyszeritve az atgondoltabb tervezesre,
nagyon szep, "valosproblemakozelibb" forrast tudunk gyartani. Egyszerubb

szepen dokumentalni, tovabbfejleszteni, talan alkalmasabb csoportmunkara

is. (De szerintem a modszeres strukturalt programozassal ugyanezt el
lehet
erni). Sza'l a C++ (objektumorientalt programozas) fejlettebb
fejlesztesi
eszkoz, aminek torvenyszeru velejaroja, hogy a futtathato kod nagyobb,
lassabb, lomhabb. (hasonlo mint assembly es magasszintu nyelvek)
Namost itt nem konkret C vs C++, hanem strukturalt vs objektumorientalt
programozasrol van szo.
(Erdekes megjegyezni, hogy a (turbo)pascal objektum orientalt
kiterjeszteset nem
is igazan nevezik objektumorientaltnak, mert ahhoz keveset tud, de ehhez

kepest (tapasztalatom szerint) hatekonyabb futtathato kod keletkezik
objektumorientalt turbo pascalbol, mint turbo c++-bol.) (a delphit
inkabb hagyjuk (nem ismerem). Tapasztalat ilyen megkozelitesbol?)

A dolog masik resze: WinApi(32) MFC. Mint tudjuk az MFC egy tok jo
(es tenyleg az) C++ eszkozkeszlet Wines alkalmazasok gyartasahoz.
Es biztos egyszerubb megalkotni ugyanazt a progit MFC-vel, mint szimpla
Winapival (Ebben sajna meg nincs konkret tapasztalatom, ijesztoen
elvarazsoltnak tunik az mfc... nincs tulbonyolitva?) Mellesleg az is
mellette
szol, hogy rengeteg MFC-s stuffhoz lehet hozzaferni.
Es termeszetesen a progi nagy, lomha, lassu (lassabb, mint mfc nelkul).
Tudom a hardware fejlodik, meg miegymas, de akkor is!
Esetleg erdekes osszehasonlitas lehet a Borlandek ObjectWindowsa,
(c-ben vagy pascalban). (Meg az is erdekes hogy az MS oprendszereken
szimpatikusabb az MFC nem ?) (vagy a fejlesztoszkozoknel nincs MS
flame?)

Tudom, nekem kell eldontenem merre megyek, de segitsetek.

Szoval Oriasi Coderek, Verbeli Developerek legyen erre velemenyetek! :-)

Es termeszetesen akkor se kimeljetek, ha marhasago(ka)t irtam ;-)

Koszi:
Tibi.

ps: igy utalag jut eszembe, hogy nyilvan lehet keverni a C-t a C++-szal,
de ugy
erzem nem illik.