IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

x86 32-bits / 64-bits Assembleur Discussion :

Problème avec RDTSC sur K6-III


Sujet :

x86 32-bits / 64-bits Assembleur

  1. #1
    Membre actif

    Profil pro
    Inscrit en
    Décembre 2002
    Messages
    339
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2002
    Messages : 339
    Points : 279
    Points
    279
    Par défaut Problème avec RDTSC sur K6-III
    Voilà, j'ai fait un prog "rapidement" qui me permet de déterminer la vitesse de mon CPU grâce à RDTSC. Le problème c'est que sur mon Duron, ça marche nickel et sur mon K6-III, l'instruction RDTSC ne doit pas être reconnue car en la remplaçant par des xor eax,eax et xor edx,edx mon prog me redonne la main. Est-ce que quelqu'un c'est quelque chose à ce sujet ?
    Si ça peut vous aider, j'ai remarqué grâce à un prog téléchargé sur le site d'haypo que mon prog n'exécutait pas les instructions SSE. Vu que je sais pas ce que c'est. Est-ce que ça a un rapport ?

    Merci d'avance à ceux qui voudront bien répondre

  2. #2
    Membre éclairé
    Profil pro
    Inscrit en
    Juillet 2002
    Messages
    842
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2002
    Messages : 842
    Points : 696
    Points
    696
    Par défaut
    A ma connaissance RDTSC ne fait pas partie du SSE. Il doit y avoir un moyen de savoir si ton proc supporte ou non cette instruction, je vais chercher. Mais je croyais que cela déclanchait une exeption quand l'instruction était invalide. un truc style InvalidOpcode. Sinon, je sais que 3DMark 2003 donne la liste de ce que ton proc supporte dont RDTSC. (J'ai vu comme ca que mon proc le supportait)

  3. #3
    Membre actif

    Profil pro
    Inscrit en
    Décembre 2002
    Messages
    339
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2002
    Messages : 339
    Points : 279
    Points
    279
    Par défaut
    Merci pour ta réponse Blustuff mais là tu m'as planté (faut dire que comme l'info c'est pas mon domaine de base, ça doit être normal, j'ai encore des choses à apprendre ;-) )

    1) Le InvalidOpcode ça serait pas une interruptions (entre 00h et 07h) par exemple ?

    2) 3DMark 2003 ??? c koi cette chose ??? En cherchant sur le web, je trouve plein de trucs dessus mais ça a rapport avec directX (moi et windows, on s'aime pas beaucoup). Tu l'as trouvé où ta doc STP ?

    Merci encore pour tout

  4. #4
    Membre éclairé
    Profil pro
    Inscrit en
    Juillet 2002
    Messages
    842
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2002
    Messages : 842
    Points : 696
    Points
    696
    Par défaut
    non, je pensait plutot a une exeption.

    3d Mark, est un benchmark pour tester les performances de ton pc. C'est un peu normal que tu ait des rapports avec directx. mais il y a quand même un truc pour savoir ce que sait faire ton proc.

  5. #5
    Membre éclairé
    Profil pro
    Inscrit en
    Juillet 2002
    Messages
    842
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2002
    Messages : 842
    Points : 696
    Points
    696
    Par défaut
    C'est bizzare je connais un AMD K6 II qui a l'instruction RDTSC.

    Sur le site d'intel cherhcec une doc qui parle de CPUID. C'était le premier resultat de la recherche pour "rdtsc". C'est que pour les intels mais j'ai testé pour 2 amds et ca marche aussi.

    J'ai programmé vite fait un truc qui te permet d'avoir des infos sur ton proc :

    http://perso.wanadoo.fr/blustuff/emu86/bug/cpu.exe.zip

    Si la vitesse de ton proc s'affiche ou si c'est ecrit qu'il supporte rdtsc, c'est qu'il le fait.

  6. #6
    Membre actif

    Profil pro
    Inscrit en
    Décembre 2002
    Messages
    339
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2002
    Messages : 339
    Points : 279
    Points
    279
    Par défaut
    J'y comprends plus rien. ça fonctionne avec ton code, il m'affiche bien ma vitesse et que la fonction RDTSC est supportée. Alors, comment cela se fasse-t-il qu'il me plante au nez uniquement lorsque mes instructions RDTSC sont présentes ???
    Voilà mon code :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
     
    ; FCPU.ASM
    ; tasm.exe /m9 fcpu.asm
    ; tlink.exe fcpu.obj
    ; sous DOS (Pentium et plus, ne marche pas sur des 8086,186,286,386 et 486 !!!)
    .486
    code   segment public use16
    assume cs:code , ds:data , ss:stacks
    debut:
    mov ax,data
    mov ds,ax
     
    mov dx,offset mess_wait
    mov ah,09h
    int 21h
     
    ; compte le nombre de cycles entre 182 appels du timer
    push ds
    mov ax,0040h
    mov ds,ax
    mov si,006Ch
    mov cx,[si]           ; compteur incrémenté à chaque IRQ0(timer appelé 18.2 fois par seconde)
    boucle_depart:
    cmp cx,[si]
    je boucle_depart
    add cx,182+1          ; 18.2065*10 = 182   & on a déjà incrémenter de 1 avec boucle_depart
    db 0Fh,31h            ; RDTSC : nombre de cycles depuis le lancement
    mov	edi,eax       ; partie basse
    mov	ebp,edx       ; partie haute
    boucle_fin:
    cmp cx,[si]
    jne boucle_fin
    db 0Fh,31h            ; RDTSC : nombre de cycles depuis le lancement
    sub	eax,edi       ; difference basse
    sbb	edx,ebp       ; difference haute
    pop ds
    ; Calcule la fréquence en MHz
    mov ecx,10*1000*1000    ; 1MHZ = 1000*1000 HZ & 18.2065*10=182
    div ecx
    inc eax
     
    mov  [frequence], eax
     
     
    ; affichage du resultat
     
    mov eax,[frequence]
    mov di,offset textx-1
    mov ecx,010d
    boucle_transfo_ascii:
    xor edx,edx
    div ecx
    add dl,'0'
    mov ds:[di],dl
    dec di
    cmp eax,0
    jne boucle_transfo_ascii
     
    mov dx,offset text
    mov ah,09h
    int 21h
     
     
    mov  ax,4C00h
    int  21h          ; sortie du prog
     
    code    ends
     
     
    data segment public use16
        frequence dd ?
     
        text     db  " Le processeur a une frequence de "
                 db  "           "
        textx    db  " MHz ",13,10,'$'
     
        mess_wait db " Attendez 10 secondes SVP",13,10,'$'
    data ends
     
     
    stacks segment stack
    remplissage db 256h dup (?)
    stacks ends
     
    end  debut
    Y'aurait-il un truc avec le mode réel ??? Si t'as une solution, ça m'intéresse.


    Au fait, comment tu fais (codement parlant) pour tester si la fonction RDTSC est utilisable avec ton prog : grâce au CPUID ou en faisant un RDTSC et en testant une exception ???

    Et encore mille merci pour ton aide Blustuff

  7. #7
    Membre éclairé
    Profil pro
    Inscrit en
    Juillet 2002
    Messages
    842
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2002
    Messages : 842
    Points : 696
    Points
    696
    Par défaut
    Je viens de lire un peu de doc. L'instruction RDTSC provoque une exeption, si le bit TSD de CR4 est à 1 et le niveau de provilège est plus grand que 0. Il n'est pas impossible que windows itnerdise l'instruction RDTSC pour les programmes 16 bits. Je connais pas du tout l'utilasion des registres CRx, mais on peut peut etre verifier leur contenu ?

    La doc intel dit qu'il y a effectivement deux methodes pour tester la présence ede RDTSC. Recuperer un exeption, ou utiliser CPUID. Il conseillent la deuxième, et elle n'est pas très compliquer. D'abord tester la présence de l'instruction CPUID, en regardant si le bit 21 du registre de flag est modifiable. Ensuite par l'instruction CPUID, on a une liste de flag dont un qui dit si oui ou non RDTSC est supporté.

    A ce propos, j'ai vu aussi pourquoi, on a du mal a avoir un nombre de cycles precis avec RDTSC. A priori, vu que les instructions peuvent être executées en parallèle, on est pas sur de quand RDTSC est executé, avant, pendant ou après l'instruction qui la suit ? Et puis le resultat change enormement d'une execution sur l'autre, cache miss occasionel ou autre chose ?

  8. #8
    Membre actif

    Profil pro
    Inscrit en
    Décembre 2002
    Messages
    339
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2002
    Messages : 339
    Points : 279
    Points
    279
    Par défaut
    si le bit TSD de CR4 est à 1
    C'est évident !!!
    Finalement, l'assembleur c'est bien le language le plus compliqué que je connaisse.


    en regardant si le bit 21 du registre de flag est modifiable
    je vais finir par croire que je suis con mais pour moi je ne connais que les flags ou sinon, la seule méthode que je vois est de faire:
    et de tester si le bit 21 est modifiable (mais là je vois pas comment, peut-être le même code mais inversé ?)

    Sinon, je pense pour ma part que le test pas le CPUID est plus intéressant.

    A priori, vu que les instructions peuvent être executées en parallèle, on est pas sur de quand RDTSC est executé, avant, pendant ou après l'instruction qui la suit ? Et puis le resultat change enormement d'une execution sur l'autre, cache miss occasionel ou autre chose ?
    Ces docs là m'intéressent si tu peux me filer les adresses STP

    Je sais pas comment te remercier Blustuff, tu es la mère Thérésa de l'assembleur

  9. #9
    Membre éclairé
    Profil pro
    Inscrit en
    Juillet 2002
    Messages
    842
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2002
    Messages : 842
    Points : 696
    Points
    696
    Par défaut
    Je n'ai plus l'adresse exacte, c'est ce que j'ai lu hier midi. Sur le site d'intel recherche RDTSC, c'est le premier resultat de la recherche. Ca s'appelle "Intel Processor Identification and the CPUID Instruction" et l'order number est : 241618-023

    Il y a des codes qui expliquent comment tester la présence de cpuid etc. Effectivement pour lire/modifier les flags au dessus de CF, il n'y a que pushfd/popfd. donc :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
     
    pushfd
    pop eax            ; recuperation deds flags dans eax
     
    mov ecx, eax       ; Sauvegarde du premier contenu des flags
    xor eax, 00200000h ; complémenter le bit 21
     
    push eax
    popfd        ; mettre la nouvelle valeur en place
     
    pushfd            
    pop eax      ; recuperer les flags modifiés
     
    xor eax, ecx ; la seule différence entre eax et ecx doit etre le bit 21
                 ; cad que le résultat de cette opération doit être 0 si le
                 ; bit 21 n'a pas changé, sinon, le resultat sera 00200000h
     
    mov CPUIDAcceptee, eax

    Sinon, le registre CR4 n'est accessible que dans le niveau de privilège 0. Les deux pcs sur lesquels tu as testé ton prog étaient sur le même os ?


    Et puis ca n'est pas l'asm qui est compliqué, mais la programmation hardware. J'ai programmé le petit logiciel en C++ avec asm integré.

  10. #10
    Membre actif

    Profil pro
    Inscrit en
    Décembre 2002
    Messages
    339
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2002
    Messages : 339
    Points : 279
    Points
    279
    Par défaut
    Merci pour la doc, je l'ai trouvé, il ne me reste plus qu'à trouver un peu de temps pour lire toutes ces pages

    Merci aussi pour le code, c'est bien ce que je pensais faire pour la détection, ça me rassure je suis par encore si nul que ça

    Les deux pcs sur lesquels tu as testé ton prog étaient sur le même os ?
    Pour explication, sur celui qui fonctionne, un Duron avec win2000 et ça tourne, sur celui qui ne fonctionne pas c'est un K6-III avec win98. Donc effectivement c'est pas le même OS. Le plus gros soucis c'est que j'ai une disquette boot DOS (où tout se charge uniquement qu'à partir du lecteur de disket), que j'ai mis mon prog dessus et que ça me refait le même cas, ça fonctionne sur le Duron et pas sur le K6-III. Y'a de quoi se prendre la tête avec ce problème

    Et puis ca n'est pas l'asm qui est compliqué, mais la programmation hardware
    C'est vrai, je me suis un peu emporté dans mon élan
    Mais au fur et à mesure que je regarde la programmation hardware, je trouve qu'avec beaucoup de docs, de temps libre et un bon niveau d'anglais, ça devient moins compliqué d'un coup.

    J'ai programmé le petit logiciel en C++ avec asm integré.
    Tout d'abord je tiens à te féliciter pour tes commentaires à la fin, c'est sympa
    Je suis pas un crack en info, les seuls langages que je parlent sont : le bon vieux basic, le bon vieux pascal(pas le delphi) et le fortran. Chu un vieux koi (Donc, quand j'ai vu tes sources de ton émulateur en C, j'ai eu quelques difficultés même si c'est pas trop difficile à décrypter le C)

  11. #11
    Membre éclairé
    Profil pro
    Inscrit en
    Juillet 2002
    Messages
    842
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2002
    Messages : 842
    Points : 696
    Points
    696
    Par défaut
    En fait, c'est pas très très logn a lire finalement, parce qu'il y a bcp de code surtout (plus de la moitié de la doc). Ca se lit très bien en diagonale, tu peux seulement lire ce qui t'interesse. Par ex, il y a un paragraphe "Comment detecter si l'instruction cpuid est supportée ?", ou "Comment retrouver le numéro de Serie du proc ?" (ce qui apparement n'est pas souvent supporté), ou encore "comment trouver la vitesse du cpu ?".

    Pour le langagee, c'est pas très grave. Beacoup se ventent de savoir utiliser 36 000 langages différents. Mais quand tu sais déja programmer, tu apprends un nouveau langage en un rien de temps. (Moi aussi j'ai fait du basic :)) j'ai commencé par Basic ST sur Atari, puis QBasic ensuite sur pc, et seulement après j'ai fait du C. puis finalement l'asm l'année dernière). Quand tu sais ecrire un algo dans un langage, tu le retranscris facilement dans un autre, il n'y a que la syntaxe qui change. Ensuite, il y a quelques concepts qui sont communs aux différents langages. La prog Win32, c'est pareil dans tous les langaes. La POO c'est pareil dans tous les langages objets. Les sources de mon émulateur sont assez barbare de toute facon, je suis assez peu conventionel. Mais je n'ai pas donné de restriction de langage. L'important c'est de savoir faire des .obj. Ensuite il n'y a qu'a les linker, peu importe que ce soit en Python, en Lysp ou je ne sais quoi. (je sais même pas si on peut compiler avec ces langages ^^)


    En fait, c'est pas très très logn a lire finalement, parce qu'il y a bcp de code surtout (plus de la moitié de la doc). Ca se lit très bien en diagonale, tu peux seulement lire ce qui t'interesse. Par ex, il y a un paragraphe "Comment detecter si l'instruction cpuid est supportée ?", ou "Comment retrouver le numéro de Serie du proc ?" (ce qui apparement n'est pas souvent supporté), ou encore "comment trouver la vitesse du cpu ?".

    Pour le langagee, c'est pas très grave. Beacoup se ventent de savoir utiliser 36 000 langages différents. Mais quand tu sais déja programmer, tu apprends un nouveau langage en un rien de temps. (Moi aussi j'ai fait du basic :)) j'ai commencé par Basic ST sur Atari, puis QBasic ensuite sur pc, et seulement après j'ai fait du C. puis finalement l'asm l'année dernière). Quand tu sais ecrire un algo dans un langage, tu le retranscris facilement dans un autre, il n'y a que la syntaxe qui change. Ensuite, il y a quelques concepts qui sont communs aux différents langages. La prog Win32, c'est pareil dans tous les langaes. La POO c'est pareil dans tous les langages objets. Les sources de mon émulateur sont assez barbare de toute facon, je suis assez peu conventionel. Mais je n'ai pas donné de restriction de langage. L'important c'est de savoir faire des .obj. Ensuite il n'y a qu'a les linker, peu importe que ce soit en Python, en Lysp ou je ne sais quoi. (je sais même pas si on peut compiler avec ces langages ^^)


    Pour ton problème, je suis désolé, là je vois vraiment pas. J'espère que quelqu'un pourra t'aider.

  12. #12
    Membre actif

    Profil pro
    Inscrit en
    Décembre 2002
    Messages
    339
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2002
    Messages : 339
    Points : 279
    Points
    279
    Par défaut
    En fait, c'est pas très très logn a lire finalement
    Effectivement, pour une fois, une doc assez courte chez intel

    j'ai commencé par Basic ST sur Atari, puis QBasic ensuite sur pc, et seulement après j'ai fait du C. puis finalement l'asm l'année dernière
    J'ai commencé le basic sur des TO5/MO7 puis sur un CPC6128 où là j'ai touché à l'assembleur pour la première fois de la vie et puis j'ai abandonné à cause des études ....

    Mais quand tu sais déja programmer, tu apprends un nouveau langage en un rien de temps
    C'est ce que je pense aussi mais faut l'avoir ce temps et il faut de la volonté aussi

    La prog Win32, c'est pareil dans tous les langaes. La POO c'est pareil dans tous les langages objets
    J'ai jamais fait justement des trucs comme ça. En fait, ce qui me casse le plus les pieds dans les langages c'est ces fameux
    ou quelque chose de ce genre. Y'a que les habitués pour se souvenir ce qu'il faut mettre à chaque fois. Moi je préfère largement les interruptions et une bonne doc, au moins tu vois ce que tu fais

    Pour ton problème, je suis désolé, là je vois vraiment pas. J'espère que quelqu'un pourra t'aider
    J'ai travaillé rapidement avec mon miniOS (avec timer) ce week-end et ça fonctionne donc je suppose que je dois avoir un défaut au niveau du proc qui m'interdit d'utiliser RDTSC en mode réel

  13. #13
    Membre éclairé
    Profil pro
    Inscrit en
    Juillet 2002
    Messages
    842
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2002
    Messages : 842
    Points : 696
    Points
    696
    Par défaut
    Tu sais "include <stdio.h>" c'est comme les includes en asm. En général tu met l'include semulement quand une fonction de ton prog est definie dans l'include. en plus "stdio" ca veut dire "standard io", donc tu sais qu'il faut le mettre dès que tu fait des entrées sorties sur la console. Mais ca se sont des fonctions standard du c++. Moi je ne les utilises presque pas, je préfère utiliser les fonctions de l'API Win32, donc les fontions de conio.h (console io). Et moi j'ai une très mauvaise mémoire, donc c'est que c'est pas utile de savoir tout par coeur. Quand tu sais pas tu as toujours l'aide sous la main qui te donne pour telle fonction quel fichier inclure si besoin est.

  14. #14
    Membre actif

    Profil pro
    Inscrit en
    Décembre 2002
    Messages
    339
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2002
    Messages : 339
    Points : 279
    Points
    279
    Par défaut
    C'est justement la raison pour laquelle je préfère le 16bits : tu fais directement les opérations, pas d'include et si t'as besoin d'une doc, ce n'est pas pour une fonction avec un lien vers un include ou quelque chose du genre mais c'est bien pour coder ton acte directement. Enfin, ça c'est mon avis et toi je sais que tu préfères le 32b.

    Merci, merci ...... (mille fois )

  15. #15
    Membre émérite

    Homme Profil pro
    Urbaniste
    Inscrit en
    Mars 2002
    Messages
    255
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Aveyron (Midi Pyrénées)

    Informations professionnelles :
    Activité : Urbaniste

    Informations forums :
    Inscription : Mars 2002
    Messages : 255
    Points : 2 717
    Points
    2 717
    Par défaut
    J'ai pas tou suivi : le problème est résolu ou non ? J'ai écrit un code en C qui lit la fréquence du CPU avec RDTSC :
    http://haypo.developpez.com/article/frequence_cpu/

    Y'a aussi du code asm de Jean-Paul MICHEL. Ce dernier utilise un petit HLT comme chronomètre de référence. Moi j'utilise le chrono de Windows ... ou alors je lis la fréquence du CPU dans /proc/cpuinfo sous Linux ;-)
    ---
    Sinon pour savoir si RDTSC est dispo, il faut effectivement appeler CPUID. J'avais écrit (il y a ... 2 ans ?) un code assembleur + interface en Turbo Pascal qui lisait ça. Je peux vous retrouver les sources si ça vous intéresse ;-)

    Au passage, j'avais bouffé pas mal de doc, mais c'est très intéressant ! On peut savoir si MMX, 3DNow!, SSE et autres sont dispo. Très utiles pour éviter un gros plantage ;-) Ca donne aussi la taille des caches L1 et L2 (à vérifier), et encore bcp d'autres infos sur le CPU !

    @+ Haypo

  16. #16
    Membre actif

    Profil pro
    Inscrit en
    Décembre 2002
    Messages
    339
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2002
    Messages : 339
    Points : 279
    Points
    279
    Par défaut
    Oui oui haypo, j'ai bien utiliser ton code et ça fonctionne sous windows. Le problème vient du fait que tous les codes que je tournent en mode réel avec l'instruction RDTSC plantent royalement. J'ai téléphoné à AMD et j'ai pas eu de réponses de leur part.

    Pour le code de Jean-Paul Michel, il ne fonctionne pas non plus. Ce qui confirme bien que le plantage vient du mode réel. J'opte donc pour un bug à la création du proc.

    Par contre, j'ai pas encore regardé si j'avais de la doc pour savoir comment déterminer la L1 et la L2 mais si tu as de la doc là-dessus ça m'intéresse, haypo .

    Il paraît que sur les K6-III, il y aurait une L3 avec certaines cartes mères. Est-ce que quelqu'un en a déjà entendu parler à part cette adresse ?
    http://www.amd.com/us-en/Processors/...8^1295,00.html

  17. #17
    Membre émérite

    Homme Profil pro
    Urbaniste
    Inscrit en
    Mars 2002
    Messages
    255
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Aveyron (Midi Pyrénées)

    Informations professionnelles :
    Activité : Urbaniste

    Informations forums :
    Inscription : Mars 2002
    Messages : 255
    Points : 2 717
    Points
    2 717
    Par défaut
    Citation Envoyé par le mage tophinus
    Par contre, j'ai pas encore regardé si j'avais de la doc pour savoir comment déterminer la L1 et la L2 mais si tu as de la doc là-dessus ça m'intéresse, haypo
    http://www.developpez.net/forums/viewtopic.php?p=642489&highlight=#642489

    Utilise CPUID pour savoir combien de cache L1 et L2 tu disposes. Voir les sites intel.com et amd.com pour plus d'info ;-)
    ---
    Je m'y connais pas du tout en mode protégé/réel. Celui dans lequel tourne Windows et Linux est le mode protégé je suppose.
    ---
    Pour ton K6-III ("Innovative TriLevel Cache™ Design") : Spécifications du K6-III

    CPUID selon AMD (sept. 2003, donc à jour !!!)

    T'as du bol, ton K6-III supporte :
    o 8000_0004h : Processor Name
    o 8000_0005h : L1 TLB/Cache Information
    o 8000_0006h : L2 TLB/Cache Information

    Tu fais alors :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    mov eax,00000001h
    CPUID
    mov [cpu],eax
    mov [feature],edx
    Ce qui donne pour eax (avec le AMD K6-III) en décomposé :
    o Extended Instruction=0
    o Extended Model=0
    o Instruction Family=5h
    o Model=1001b (9h)

    et dans edx :
    o bit 4 = Time Stamp Counter (with RDTSC and CR4 disable bit)
    ---> Pages 53 et 56 du PDF.

    ---

    Liens intéressants (Intel) :
    - Using the RDTSC Instruction for Performance Monitoring (pdf)
    - Survey of Pentium® Processor Performance Monitoring Capabilities & Tools
    - Using the RDTSC Instruction for Performance Monitoring
    (sur Pentium 2)

    @+ Haypo

  18. #18
    Membre actif

    Profil pro
    Inscrit en
    Décembre 2002
    Messages
    339
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2002
    Messages : 339
    Points : 279
    Points
    279
    Par défaut
    yes merci pour l'adresse. Mais comme je lis les posts du plus ancien au plus nouveau, j'ai vu l'adresse qu'après.

    Et merci pour les liens, je vais regarder ça

Discussions similaires

  1. [XI] problème avec groupe sur un champ trié par origine ?
    Par kikidrome dans le forum SAP Crystal Reports
    Réponses: 6
    Dernier message: 11/04/2007, 15h31
  2. [FTP] Problème avec fopen sur URL
    Par Biboune2008 dans le forum Langage
    Réponses: 14
    Dernier message: 22/06/2006, 17h00
  3. problème avec select sur onchange
    Par Kerod dans le forum Général JavaScript
    Réponses: 6
    Dernier message: 01/12/2005, 14h05
  4. Problèmes avec INTERSECT sur MYSQL
    Par zarbydigital dans le forum Requêtes
    Réponses: 1
    Dernier message: 27/09/2005, 13h18
  5. Problème avec OnDrawColumnCell sur un DBGrid
    Par n1portki dans le forum Composants VCL
    Réponses: 3
    Dernier message: 23/09/2005, 04h18

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo