[ROZWIĄZANE] Wartości funkcji tickcount dl...
Gość_21977_* 28.03.2013
Oficjalna dokumentacja funkcji rdzennej tickcount opisuje jej działanie jako nieznane.Mimo wszystko postanowiłem poznać jej działanie i opisać w polskojęzycznej dokumentacji.
Dotarłem więc do kodu źródłowego, który wygląda następująco:
Kod jest dość mocno nieczytelny, dużo komentarzy, jednak z tego, co zrozumiałem,
funkcja przyjmuje początkowo wartość ⌊-232-1/106⌋ i co cykl zegara ulega inkrementacji aż do ⌊(232-1-1)/106⌋, po czym tickcount przekracza wartość INT i wraca do wartości minimalnej.
Opisałem to w dokumentacji: tickcount
, jednak nie wiem w jaki sposób funkcja zachowa się serwerów HLDS pracujących na architekturach 64 bitowych, do tego nie mam jak tego przetestować.
I tu wychodzę z zapytaniem, czy wynik rzutowania wyniku na zmienną całkowitoliczbową w architekturze 64 bitowej będzie inny, niż w przypadku architektury 32 bitowej i jeśli tak, to jakie będzie ekstremum funkcji tickcount?
Użytkownik Benio101 edytował ten post 28.03.2013 18:20
drobne techniczne
Dotarłem więc do kodu źródłowego, który wygląda następująco:
static cell AMX_NATIVE_CALL _tickcount(AMX *amx, cell *params)
{
// #if defined __WIN32__ || defined _WIN32
// static int timerset = 0;
// #endif
cell value;
assert(params[0]==sizeof(cell));
//#if defined __WIN32__ || defined _WIN32
// if (!timerset) {
// timeBeginPeriod(1); /* timeGetTime() is more accurate on WindowsNT
// * if timeBeginPeriod(1) is set */
// timerset=1;
// } /* if */
// value=timeGetTime(); /* this value is already in milliseconds */
// #else
value=(cell)clock();
/* convert to milliseconds */
value=(cell)((1000L * (value+CLK_TCK/2)) / CLK_TCK);
//#endif
return value;
}
Kod jest dość mocno nieczytelny, dużo komentarzy, jednak z tego, co zrozumiałem,
funkcja przyjmuje początkowo wartość ⌊-232-1/106⌋ i co cykl zegara ulega inkrementacji aż do ⌊(232-1-1)/106⌋, po czym tickcount przekracza wartość INT i wraca do wartości minimalnej.
Opisałem to w dokumentacji: tickcount

I tu wychodzę z zapytaniem, czy wynik rzutowania wyniku na zmienną całkowitoliczbową w architekturze 64 bitowej będzie inny, niż w przypadku architektury 32 bitowej i jeśli tak, to jakie będzie ekstremum funkcji tickcount?
Użytkownik Benio101 edytował ten post 28.03.2013 18:20
drobne techniczne
GwynBleidD
29.03.2013
Więc tak, najpierw przyjrzyjmy się czym jest typ "cell". Wszystko zależy o tej definicji:
Teraz druga kwestia: jaki typ danych zwraca clock? Zwraca on typ clock_t, który jest aliasem do typu mogącego przechować liczbę ticków w danym systemie, czyli prawdopodobnie dla 32 bitowego systemu będzie to 32 bity, dla 64 będą to 64 bity.
No dobrze, więc na pewno nie zejdziemy poniżej 32 bitów. Pytanie teraz co do znaku. Nie jest jasno określone, czy clock_t jest signed, czy nie. Co ma wpływ na rzutowanie. Rozpatrzmy więc 4 przypadki:
Drugi przypaek: z int64 na int32. Najpierw zostanie przepisany znak liczby, następnie zostaną przepisane młodsze bity tak, aby znaku nie zmienić. Więc znak liczby zostanie zachowany. Niemiła troszkę w tym przypadku sytuacja, przy rosnącej non stop wartości ticków najpierw zmienna przy przepełnieniu 32 bitów będzie wracać do 0, następnie po przepełnieniu 64 bitów, 32 bitowa zmienna powędruje na ujemne wartości i tam będzie sobie oscylować, dopóki 64 bitowa nie przekroczy zera.
Trzeci i czwarty przypadek: rzutowanie ze zmiennej bez znaku. Tu nie ma znaczenia, czy z 64 bitowej, czy z 32 bitowej to nastąpi, za każdym razem po prostu 32 młodsze bity zostaną przepisane, tworząc również znak liczby. Sytuacja taka, jak w int32, ale nie zachowujemy tu znaku (bo wcześniej go nie było).
Więc jeśli ticki są liczone na zmiennej ze znakiem, to twórcy AMX popełnili wielki błąd, gdyż nie będą się one zachowywały prawidłowo na 64 bitowych systemach.
#if !defined PAWN_CELL_SIZE #define PAWN_CELL_SIZE 32 /* by default, use 32-bit cells */ #endifCzyli domyślnie mamy 32 bity. Cell jest zmienną ze znakiem, ucell bez.
Teraz druga kwestia: jaki typ danych zwraca clock? Zwraca on typ clock_t, który jest aliasem do typu mogącego przechować liczbę ticków w danym systemie, czyli prawdopodobnie dla 32 bitowego systemu będzie to 32 bity, dla 64 będą to 64 bity.
No dobrze, więc na pewno nie zejdziemy poniżej 32 bitów. Pytanie teraz co do znaku. Nie jest jasno określone, czy clock_t jest signed, czy nie. Co ma wpływ na rzutowanie. Rozpatrzmy więc 4 przypadki:
- Rzutowanie ze zmiennej int32
- Rzutowanie ze zmiennej int64
- Rzutowanie ze zmiennej uint32
- Rzutowanie ze zmiennej uint64
Drugi przypaek: z int64 na int32. Najpierw zostanie przepisany znak liczby, następnie zostaną przepisane młodsze bity tak, aby znaku nie zmienić. Więc znak liczby zostanie zachowany. Niemiła troszkę w tym przypadku sytuacja, przy rosnącej non stop wartości ticków najpierw zmienna przy przepełnieniu 32 bitów będzie wracać do 0, następnie po przepełnieniu 64 bitów, 32 bitowa zmienna powędruje na ujemne wartości i tam będzie sobie oscylować, dopóki 64 bitowa nie przekroczy zera.
Trzeci i czwarty przypadek: rzutowanie ze zmiennej bez znaku. Tu nie ma znaczenia, czy z 64 bitowej, czy z 32 bitowej to nastąpi, za każdym razem po prostu 32 młodsze bity zostaną przepisane, tworząc również znak liczby. Sytuacja taka, jak w int32, ale nie zachowujemy tu znaku (bo wcześniej go nie było).
Więc jeśli ticki są liczone na zmiennej ze znakiem, to twórcy AMX popełnili wielki błąd, gdyż nie będą się one zachowywały prawidłowo na 64 bitowych systemach.
Gość_21977_* 30.03.2013
Wiadomość wygenerowana automatycznie
Ten temat został zamknięty przez moderatora.
Powód: Pomoc udzielona
Jeśli się z tym nie zgadzasz,
raportuj ten post, a moderator lub administrator rozpatrzy go ponownie.
Z pozdrowieniami,
Zespół AMXX.PL
Ten temat został zamknięty przez moderatora.
Powód: Pomoc udzielona
Jeśli się z tym nie zgadzasz,

Z pozdrowieniami,
Zespół AMXX.PL