TCH (statz) | #1, Főfasz (10443) |
1579 | #299b | ^ | Idézet | Sun, 29 Dec 2013 12:36:07 +01 |
31.46.*.* | *.catv.pool.telekom.hu |
Mert fingom sincs, hogy hogy korrigálhatnék 5 nanoszekundumnyi csúszást. :] A nanoszekundumos tartomány már jócskán a mai PC-k órajelideje (1/GHz = ns), ennek megfelelően ns nagyságrendű csúszásokat nem lehet kimérni: ha az asm kódban erre lenne vizsgálat, akkor már az is belezavarna ennyit vagy annyit, ha meg még a korrigálás is benne lenne, (pl. NOP injektálás valahova, vagy egy NOP blokk átugrásának újraparaméterezése), akkor az meg pláne. A végeredmény sokkal nagyobb csúszás lenne, mint amit korrigálni akartam. Egy 2.4 GHz-en járó magon egy "tick" vagy más néven ciklus az usque 0.41 + 2/3 ns. Egy utasítás végrehajtása 2-N ciklusig tart, tehát már pl. egy NOP utasítás is megeszik majdnem 1 ns-t és akkor még nem is csináltunk semmit. Egyszerűen arról van szó, hogy egy X GHz-es processzoron (ahol X < ~50) nem lehet nanoszekundumnyi eltéréseket korrigálni. Pontosabb ciklust talán lehet írni, de menetközbeni korrigálásra nincs esély, mert ahogy leírtam, a korrigálásra szolgáló utasítások nagyobb differenciát eredményeznének, mint amennyi eredetileg volt. Nyilván nem, de ez az én kódom esetében irreleváns, mert párhuzamos port a notikon már baromi régen nincsen. Nem kerestek épp embert az Empohoz? Mert én épp állást keresek. |
saxus (statz) | #9, Agyfasz (419) |
218 | #299c | ^ | Idézet | Sun, 29 Dec 2013 14:24:02 +01 |
81.182.*.* | *.pool.t-online.hu |
Hulye kerdes, de ha levonnal 5-ot itt?cusleep_time := $100000000 div (((tv.tv_sec * 1000000) + tv.tv_usec) - bt); Btw. ebben az AT&T stilusu ASM kodban forditva van a cel es a forrasregiszter a MOV-nal? |
saxus (statz) | #9, Agyfasz (419) |
134 | #299d | ^ | Idézet | Sun, 29 Dec 2013 14:40:53 +01 |
81.182.*.* | *.pool.t-online.hu |
Hja es nem. Karacsony elott szoktunk altalaban embereket keresni, de akkor is sales es raktar temakorben. IT-re csak kihalasos alapon. |
TCH (statz) | #1, Főfasz (10443) |
1382 | #299e | ^ | Idézet | Sun, 29 Dec 2013 17:24:44 +01 |
31.46.*.* | *.catv.pool.telekom.hu |
Nem hülye kérdés, mert a ciklusszám basztatásával valóban lehet ezen még hangolni és közelebb mászni a célhoz 1-2 ns-el; csak egy a baj: mennyit vonjunk le, vagy adjunk hozzá? Konstans 5 nem biztos, hogy jó, mert ez ciklusszám, ami egyik gépen ennyi idő, másikon annyi, sőt, akár ugyanazon a gépen is, egyik futásnál ennyi, másiknál annyi, az órajel függvényében. Szóval jó helyen keresgészel, csak az a baj, hogy még mindig nem tudjuk kimérni, hogy mennyi az annyi. Max esetleg úgy, hogy méri 10 másodpercig és a várt/mért különbségből számol egy offsetet. De akkor így a program inicializálása baromi sokáig fog tartani. Az intelhez képest igen, fordítva van, de amúgy az inteles a fordított. Kicsit nekem is szokatlan így x86 kódot írni, de így azért logikusabb, hogy elöl a forrás, hátul a cél (68k-n is így van), meg az is reálisabb, hogy én specifikálom az operandus hosszát (az is így van 68k-ban). Meg ami még fontosabb, ezt a szintaxist támogatják a fordítók, nem csak a FreePascal, hanem a GCC és a CLang is. (Mondjuk FP az támogatja az inteles szintaxist is, csak át kell kapcsolni.) Remek. |