> Felado :  [Hungary]
> Tegnap a vegere elfelejtettem egy _csak_ Pentiumokon alkalmazhato
> modszert irni:
> 
> A Pentiumnak van egy 64 bites szamlaloja, amit minden orajelnel
> eggyel novel. Az rdtsc (read time stamp counter: 0x0F 0x31)
> utasitassal lehet leolvasni, az edx::eax regiszterekbe rakja az
> aktualis allast.

Ez jo! Mire nem vezet, ha az ember ismeri a processzort, amin dolgozik
 ... :-)

Egyebkent az NT-n van olyan fuggveny (KeQuerySystemTime(), DDK), ami
100nsec-os felbontasban adja meg az idot (es a visszaadott ertek egy
LARGE_INTEGER):

"System time is a count of 100-nanosecond intervals since January 1,
1601."

Valoszinuleg a fentiek alapjan mukodik - maskeppen nehez elkepzelni.

Win32-bol (user modebol) nem elerheto, bar a FILETIME struktura hasonlo,
de csak a fajlok pontos idejet lehet megtudni es Win95 alatt csak 2sec
a felbontas - ahogy az regen is szokasos volt.
-- 
Tibor

Sziasztok!

 Bocs, hogy csak ugy kutyafuttaban irok:

Ez a szoveg a SAC/TEXT/Pentopt.zip file-ban van:
> -------------------------------------------------------------------------
19.1 Moving data
----------------
Floating point instructions can be used to move 8 bytes at a time:
FILD QWORD PTR [ESI] / FISTP QWORD PTR [EDI]
This is only an advantage if the destination is not in the cache. The
optimal way to move a block of data to uncached memory on the Pentium is:

TopOfLoop:
FILD QWORD PTR [ESI]
FILD QWORD PTR [ESI+8]
FXCH
FISTP QWORD PTR [EDI]
FISTP QWORD PTR [EDI+8]
ADD ESI,16
ADD EDI,16
DEC ECX
JNZ TopOfLoop

The source and destination should of course be aligned by 8. The extra time
used by the slow FILD and FISTP instructions is compensated for by the fact
that you only have to do half as many write operations.  Note that this
method is only advantageous on the Pentium and only if the destination is
not in the cache. On all other processors the optimal way to move blocks of
data is REP MOVSD, or if you have a processor with MMX you may use the MMX
instructions instead to write 8 bytes at a time.
> -------------------------------------------------------------------------

Remelem mindenkinek ertheto. En egy kicsit onzonek erzem a megoldast. :)
Annyit tennek meg hozza, hogy az altalam ismert leggyorsabb x86 memcopy
a PREFETCH/unrolled MOVQ. No igen, PREFETCH csak K6-3D-ben es attol felfele
van, de hat ha szabad Pentiumra/PProra(??) optimalizelni, akkor erre miert ne
lehetne? :)

Balala 
Ui: Mi a frasznak talaltak ki a DMA-t? Hulye PC!...
Ui2: Ok, ez igy komolytalan, csak gyorsan helyesbiteni akartam, ha lesz idom 
(98 augusztus) visszaterek ra.

On 18 Apr 98 at 15:11,  > 
wrote:

> Kellene nekem egy olan TSR ami tudja azt, hogyha a
> billentyuzeten megnyomok 1 adott billentyut (pl : Num
> Pad 5 -os ) akkor elinduljon egy program. A program

Az, hogy akkor induljon el, az eleg nehez dos-ban. Nem biztos, hogy 
van szabad memoria pl. Jobb, ha eleve bent van a memoriaban.

> maga nem csinalna mast, mint egy text filet-t meg-
> jelenitene.  Pl : egy ASM forraskodot editalgatva kell
> 1 kis info egy parancsrol, akkor az megjelenjen, es addig

Vannak tsr-ek, amik pont ezt csinaljak. Pl. a NortonGuide.

> PS: Peldaul az int 16h -ban ha magamra iranyitom,
>        tetszoleges ideig idozhetek ?

Igen. Pontosabban:

Ketfele dolgot erdemes csinalni: Be kell koltozni egyreszt az 
int16-ba, masreszt az int28-ba. Nemely program az int16-ot hivogatva 
varakozik esemenyre, masoknal meg billentyure varas kozben a dos az 
int28-at hivja meg.

Viszont csak akkor szabad dos fuggvenyeket (file nyitas, stb.)
meghivni, ha a dos eppen nem fut, mert a dos nem reentrans. Van egy
valtozo, amit a dos novel, amikor fut egy int21-es fuggveny: InDOS
flag-nek is nevezik. (a 34h-s int21-gyel lehet a cimet lekerdezni) 
Int16-ban csak akkor szabad dos-t hivni, ha ez a flag 0. Int28-ban 
csak akkor, ha 0 vagy 1.

Ha a kivant pillanatban (amikor a NumPad5-ost megnyomjak) eppen
rosszul all az InDOS flag, akkor egy valtozot erdemes beallitani,
hogy majd dolgozni kell, es a kovetkezo alkalmakkor (int16 vagy
int28 hivaskor) figyelni, hogy szabad-e mar dos-t hivni, es csak 
akkor dolgozni.

István
--  Istvan Marosi  --  http://www.sch.bme.hu/~marosi  --
--  Recosoft Ltd.  --  mailto:  --

On 18 Apr 98 at 8:07,  > wrote:

> Na bumm, a Clipperrel mellefogtam - az ungetch()-ra en is gondoltam,
> csak nem ertettem egeszen, hogy C-ben kellene a Keyboard fuggvenyt meg-
> irni... :-)

Az ungetch csak 1 melyseget tud visszanyomni tudtommal. De ha ez 
eleg, akkor persze OK.

István
--  Istvan Marosi  --  http://www.sch.bme.hu/~marosi  --
--  Recosoft Ltd.  --  mailto:  --

On 18 Apr 98 at 10:36,  > wrote:

> szakmai artalom? szamomra (mint a fizikaban mindig) a pozitiv korbejarasi
> irany az oramutato jarasaval ellentetes irany (vagyis a pozitiv
> trigonometrikus irany). Megprobaltam de egyszeruen nem birok egy
> teglalapot jobbra fordulva korbejarni, olyan ez mint fejen allni :-]

:)))

Az egesz megegyezes kerdese :)) Ha viszont az a megegyezes, hogy egy 
elvektor (élvektor) jobb oldalan van a fekete pixel, bal oldalan a 
feher, akkor ez mar meghatarozza, hogy az oramutato jarasaval 
_azonos_ (tehat negativ) iranyba jarod korbe az alakot.

> >fordulunk; ha konkav, akkor ide-is, oda-is, de a "belso"
> >csucsoknal az ellenkezo iranyu fordulas mindig "kiejt" egy sima
> 
> valami azert nem volt tiszta, tomor alakzatokrol beszeltunk vagy sem?

Tomorrol, persze.

> Azt hiszem csak en gondoltam ugy...bar volt szo lyukrol de nem emlekszem
> karikara vagy gyurure.

Masrol volt fentebb szo:

    x   x
    x x x
    x x x

Felul a bemelyedesben, a kihagyott pixel helyen ilyen fordulasok
jonnek egymas utan: jobbra, balra, balra, jobbra. Minden balra 
fordulasnak van egy jobbra parja, ezek kiejtik egymast.

István
--  Istvan Marosi  --  http://www.sch.bme.hu/~marosi  --
--  Recosoft Ltd.  --  mailto:  --