🚀 go-pugleaf

En <news:01c5c0cd$b9ffb9a0$6801a8c0@ramislap>, Alcor va escriure:
> personnellement, j'utiliserait l'approche inverse : on boucle pendant
> un temps fixe et on regarde jusqu'o� on est arriv� � compter. ce
> nombre sera alors � multiplier par la dur�e demand�e.
>
> par exemple on peut d�tourner l'interruption 1C le temps du
> chronom�trage. (elle est appel�e 18,2 fois par seconde)
[couic]
> ne pas oublier de faire un test de d�bordement du compteur. j'utilise
> des INT64 et sur un p4 � 2.6GHz �a montait � 15.000.000 cycles.

Autrement dit, 5800 cycles par MHz, ou (c'est pareil) un temps de cycle de
170 ticks CPU.

> mais un jour, �a d�bordera, c'est juste une question de temps.

Avec des entiers sur 64 bits, tu as quand m�me un peu de temps: en supposant
que ni les architectures ni les optimisateurs ne progressent (m�me temps de
cycle), le d�bordement arrivera (en sign�) pour une fr�quence de 1400 EHz.
Avec un temps de cycle r�duit � 1 tick, une belle optimisation, on est
encore dans des fr�quences de l'ordre de 8 EHz, plus de 2 milliards de fois
mieux qu'� l'heure actuelle. Attention aux interf�rences!


Mais je vois un probl�me avec ta m�thode: sous DOS, les compilateurs 16 bits
(susceptibles de s'interfacer directement avec l'interruption 0x1C) ne sont
pas capables de manipuler des donn�es enti�res sur 64 bits dans des
conditions non prohibitives. La tentation va donc �tre grande de prendre un
compilateur 32 bits (genre DJGPP); cela va donc faire intervenir le temps de
phase de l'h�te DPMI, ce qui va rendre un peu plus compliqu� le calcul du
temps de base de la boucle (il va au moins falloir faire une interpolation
lin�aire).


Antoine