tick counter und rdtsc

jsbach

Hallo Zusammen,

Ich habe etwas in c programmiert, das nebenbei Zeitmessungen machen muss.
Da die Aufloesung von clock() auf x86 und x86_64 schlecht ist, habe ich
fuer Alternative gegoogelt und "rdtsc" als Loesung gefunden.
http://en.wikipedia.org/wiki/RDTSC

Ich wollte diesen Code aus dem Link oben benutzen:

__inline__ uint64_t rdtsc() {
           uint32_t lo, hi; 
           __asm__ __volatile__ (      // serialize
                        "xorl %%eax,%%eax \n        cpuid"
                        ::: "%rax", "%rbx", "%rcx", "%rdx");
           __asm__ __volatile__ ("rdtsc" : "=a" (lo), "=d" (hi));
              return (uint64_t)hi << 32 | lo;  
              }

Ich wollte fragen ob ich diese Code fuer x86 und x86_64 Architekturen sicher
einsetzen kann. Und wieso kriege ich ne Fehlermeldung von der Zeile mit
"serialize" Kommentar? Die Fehlermeldung von gcc ist:

src/server.c:26: error: PIC register ‘%rbx’ clobbered in ‘asm’

Wenn ich in einer Schleife Differenz aus zweier Ticks(start , finish) mache,
muss ich darauf achten ob die Werte ge-nullt wurden?
Die Code hierzu steht hier bei ansi-c foren zu sehen:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-211161.html

Danke fuer jede Hilfe!

Nimm doch besser die API deines Betriebssystems:
WinAPI: GetTickCount oder QueryPerformanceCounter/QueryPerformanceFrequency
Linux: times oder clock_gettime

sothis_

[...]each time you call PLT entry, ensure ebx contains address of your GOT. And remember tht ebx is callee-saved register[...]

mit anderen worten wenn du position independent code, also zum beispiel dynamische bibliotheken mit inline assembler erzeugst, musst du sicher stellen, dass ebx/rbx unangetastet bleibt, bzw. der ursprüngliche wert vor dem return wiederhergestellt wird. als raus damit aus der clobber list, in der du ja alle register aufführst, deren inhalt verändert wird. es sei denn cpuid benutzt es als rückgabe register, da bin ich mir jetzt nicht sicher. falls, dann sichere rbx vorher in ein anderes register und stelle es nach rdtsc wieder her. ansonsten bleibt noch zu sagen das der tsc bei multiprozessor/multikernprozessor systemen und bei systemen mit dynamischer taktfrequenzverwaltung (z.b. mit cpufreq unter linux) sehr unzuverlässig ist. von daher nutze wirklich lieber die bereitgestellten funktionen des betriebssystems, da sie in der regel per default den höchstauflösenden timer im system benutzten (z.b. HPET, wobei das unter linux auch noch etwas buggered is :().