Hi  !
>/az en doxxom, es az intel hivatalos doxxa annyival +tolgya,
>hogy 'rather than its value'... vagy valami hasollok... sza'l
>a dest-be beleteszi scr offsetjet... /nem az erteket!/ magyarul
>a lea di,[dest] egyenlo mov di,offset dest.... stimmol?!?? de ha
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
iC> helyesen igy lenne:
iC> lea di, valtozo == mov di, offset valtozo
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
na mos' a 2 leiras koszt csak annyi a kulonbseg, hogy
en [] be tettem a lea nal levo doogokat.. /azert, mer'
a memko hivatkozast [] be illik tenni...;)))) persze
meg mijelott aszondod, nagyon kristajtisztan tudom,
hogy a lea _NEM_ nyul !SOHA! a memkohoz, csak az
offset-et, amit a memkohoz irsz aszt beteszi a peldaban
di-be... /aze' szokas viszon' eszt igy mem konvenciyonak
irni, mer'hogy a kodolasa is tok ugyanugy megy, min'
barhol mashol a memko kodolasa... es szerintem a legtobb
proggizot eppen ez a 'memkos' kodolas zavarja be, es
eze' hiszik aszt, hogy ez kiolvas bamit is a memkobo'pedig nem is;))
iC> Tomoren ez a kulombseg, mert ha azt mondtad volna, hogy mov di, valtozo,
iC> akkor di-be a valtozo erteket tenne bele az offsetje helyett. Ami viszont
iC> mar lenyeges kulonbseg a ket megoldas kozott, hogy a lea tud szamolgatni
iC> is:
iC> lea di, [bp+bx+97] stb....
igen.. ez az, amit en ugy irtam le, hogy 'aritmetikai' muvlet a lea,
mer' ebben az esetben di:=bp+bx+97 pacalos +fogalmazassal elve;))))
/es ez az, amire par szammal ezelott leirtam, hogy lehet vele
truncateltetni /and $ffff/ vagy eppen zerofillelni /ha lea edi,[di]...;)))
sza'l 1 csomo minden masra is lehet haszlani...;)))0
iC> A les pedig egy valtozobol veszi ki a szegmens es offset cimeket:
iC> les di, valtozo
iC> valtozo dd itt_van_egy_cim_segmens:offset_formaban
igen... bar monnyuk a tarolasa eppen a forditott sorrend,
sza'l dw ofs,seg, vagy yobb esetben dd ofs;dw seg/sel;))))
iC> Turbo Pascalban ez pl igy nezhet ki:
iC> procedure vala(var d:word);
iC> var w:word;
iC> begin;
iC> asm
iC> les di,d {megkapod az es:di-ben a pointer erteket...}
iC> mov ax, es:[di] {...tehat ax-be be tudod tolteni a wordod tartalmat}
iC> lea di,d {igy viszont a pointer tipusu valtozod, azaz a d nevu
iC> pointered offsetjet kapod meg!}
___________________________________
iC> mov di,word ptr ss:[di] {...szoval igy a pointer elso wordjet,
iC> azaz az valtozod offsetet kapod meg}
iC> mov ax,word ptr ss:[di+2] {...ez pedig valtozod szegmense lesz}
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
na igen... ez az a pont, ahonnan mar be foxx bugzani...
mer'hogy az az Lso muvelettel felulirtad a di-t.. sza'l
ez igy nem teyyesen koser, a 2 sort +forditva irtam vo'na
a heyedben, es ugy muxxott vo'na....;)))))))))))))))))
iC> mov es, ax {attoltod a szegmens cimet az es-be}
monnyuk iyen erovel ma' eleve mov es,[mem] -et is lehet csinalni..
aszt, hogy a pacal engedi-e, aszt nemtom, de abban viszont bisztos
vagyok, hogy ez 386- muvelet, sza'l 286on /es elotte/ is rohogve megy,
sza'l ha a pacal nem engedi, akko' 1 uyabb erv a pacal_suxx4eva mellett;))))
iC> mov ax, es:[di] {ujra be tudtad tolteni az ax-be a wordod tartalmat,
iC> csak kisse bonyasan}
iC> end;
iC> end;
iC> ehelyett inkabb igy csinaltam volna:
iC> procedure vala(d: word); assembler;
iC> asm
iC> mov ax, d {hmmmm, sokkal egyszerubb...}
iC> end;
na igen, csak mi nem wordot akartunk tolteni... sza'l
mi 1 cimre vo'ttunk kivancsiyak, es vegulis nem is
vo'tt +mondva, hogy mivele az a cim... sza'l annyi
vo'tt a kiindulasi feladat, hogy proc vala(var d);
es akko' oda kelett vo'na bepakooni asszem 1 bytet...
/de lehet, hogy nem 1 bytet akart irni az illeto,
mer' arra ott a functijon, es a mov @result,al...;)))
Mc
|
>Sziasztok !
>
>A kerdesem az lenne, hogy vajon a Celeron alatt BP 7-essel forditott
>proggik miert allnak le zero divide (0. kivetel) hibaval ?
>Es vajon sima Pentiumon miert nem tortenik meg ugyanez?
>Szoval en vegigdebugoltam egy ilyen proggit, es a kovetkezo kodnal
>lepett fel a kivetel
>...
>not dx ; DX:AX -en valami hatalmas ertek lesz
>mov cx,0037h
>div cx ; ezutan az eredmeny >65535
>
>Annyit tudok, hogy a 0. kivetelt okozhatja az is, hogy az eredmeny
>nem fer el az AX-ben. Itt eppen ez tortenik valoszinuleg.
>De akkor ez miert nem fordul elo egy olyan konfigon, amelyben "csak"
>a processzor kulonbozik (konkretan P133) ?
>
>Az is jo lenne, ha valaki meg tudna mondani mit kavar ilyenkor a
>Pascal ? Valoszinuleg a crt unit inicializacios kodjaban lehet
>valami (a begin end. kozott). Lehet, hogy a CRT forrasa is segiteni
>tudna.
>
>Ha ezt leforditom:
>begin
>end.
>akkor minde ok.
>
>Viszont ha fejlesztem egy kicsit:
>uses crt;
>begin
>end.
>Akkor fellep a 0. kivetel.
Haliho!
Nekem is ugyanez a problemam volt nehany honapja.
A gubanc a CRT unitban van. Ugyanis amikor probalja beallitani a delay
varakozasi erteket, a procid olyan gyors, hogy 0 ido alatt vegrehajtja a
tesztelo reszt, es ezzel az ertekkel akar osztani, hogy ki tudja szamolni a
delay valos erteket. (Huhh, szep magyar mondat)
Maganba elkuldom a patchelt CRT unitot.
--
JimBoo  >
|
