[ROZWIĄZANE] Wartości funkcji tickcount dla 64 bitów

Oficjalna dokumentacja funkcji rdzennej tickcount opisuje jej działanie jako nieznane.

• AmxModX.org Documentation :: tickcount

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:

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ść ⌊-2^32-1/10⁶⌋ i co cykl zegara ulega inkrementacji aż do ⌊(2^32-1-1)/10⁶⌋, 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

Więc tak, najpierw przyjrzyjmy się czym jest typ "cell". Wszystko zależy o tej definicji:

#if !defined PAWN_CELL_SIZE
  #define PAWN_CELL_SIZE 32	 /* by default, use 32-bit cells */
#endif

Czyli 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

W pierwszym przypadku nie mamy właściwie do czynienia z rzutowaniem. Typy są takie same, więc wartość po rzutowaniu się nie zmieni.
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.

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