1. |
Signum fgv? (mind) |
46 sor |
(cikkei) |
2. |
mfc vs winapi (mind) |
58 sor |
(cikkei) |
|
+ - | Signum fgv? (mind) |
VÁLASZ |
Feladó: (cikkei)
|
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
|
+ - | mfc vs winapi (mind) |
VÁLASZ |
Feladó: (cikkei)
|
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.
|
|