Calcul FP et SSE

[fefe]

Je ne sais pas ce que tu veux visualiser, mais je me souviens d'avoir hacke Bochs pour generer des traces d'adresses memoire pour utiliser dans des simulateurs de caches et TLB.

[fefe]

Si c'est juste les algo. un qui était utilisé par les Pentium et qui était mal implémenté (bug fdiv) était le SRT radix 4.

Toute la lignee P6 utilise un SRT radix-4, jusqu'a Penryn . P4 utilisait un Radix-2 double pumped.

[Lissyx]

Je ne sais pas ce que tu veux visualiser, mais je me souviens d'avoir hacke Bochs pour generer des traces d'adresses memoire pour utiliser dans des simulateurs de caches et TLB.

Bah clairement, ce qui m'intéresserait, ce serait de pouvoir faire du debug pas à pas du code qui tourne dans l'hôte Bochs, en ayant une vue globale du CPU (registres, pile, etc).

[jihef]

Tu peux faire ça juste avec un débuggeur. Y'a Ollydbg qui est pas mal.

[fefe]

Registres, pile tu as deja dans un debugger standard, ce que tu peux avoir en plus avec Bochs c'est de lire toute l'architecture qui n'est habituellement visible qu'en ring0 (CR/MSR...). En codant un peu tu peux aussi avoir une idee de l'etat de certaines structures microarchitecturales (cache/tlb/predicteurs etc...) mais ce que tu verras dependra surtout de la qualite de ton modele vis a vis du hardware.

[Lissyx]

Oui, mais un debugger ça n'ira pas

C'était pour voir comment fonctionnait un MBR particulier que j'avais besoin de ça ... et ça me revient en tête maintenant.

[fefe]

Si tu veux debugger un OS pendant le boot effectivement tu peux le faire comme ca, mais tu ne vas pas rigoler si ce sont des IO que tu cherches a debug.

[Lissyx]

Non, normalement, y'a pas beaucoup d'I/O dans ce que je veux voir. Mais du côté de Bochs, à part un BFE qui ne semble plus maintenu, je trouve rien :/

Et pour qemu, ça ne semble faisaible que si tu lances un noyau linux à la main ...

[Alice]

Il existe également une grosse astuce qui consiste à additionner à un nombre flottant une constante qui va bien, ce qui permet un cast en entier pratiquement gratuit.

Hey hey... c'était d'ailleur très rigolo! D'ailleurs voilà du code en C qui fait la chose. Une méthode qui converti un double en int32_t et une qui fait la conversion d'un float en uint16_t.

union dblint
{
	int32_t i32;
	int64_t i64;
	double	d;
};

inline int32_t double2Int(double d)
{	
 	dblint tmp;
	
	/* 0x4338000000000000 = (1 << 51) + (1 << 52) */
	tmp.i64 = 0x4338000000000000; 
	tmp.d  += d;		
	
	return tmp.i32;
}

union fluint16
{
	uint32_t i32;
	uint16_t i16;
	float 	 f;
};

inline uint16_t float2Uint16(float f)
{	
	fluint16 tmp;		
	
	/* 0x4B400000 = (1 << 23) + (1 << 22); */
	tmp.i32 = 0x4B400000;	
	tmp.f  += f;
		
	return tmp.i16;
}

Que du bonheur

[fefe]

La derniere fois que j'ai demarre Bochs c'etait il y a 7 ans...

[Neo_13]

Hey hey... c'était d'ailleur très rigolo! D'ailleurs voilà du code en C qui fait la chose. Une méthode qui converti un double en int32_t et une qui fait la conversion d'un float en uint16_t.


Que du bonheur

c'est là que je me rend compte que je suis vraimetn très mauvais en programmtion

d'ailleurs parfois je me demande si je suis le seul non-codeur du coin...

[Lissyx]

La derniere fois que j'ai demarre Bochs c'etait il y a 7 ans...

Tant pis. ...

[jihef]

Avec le debugger de Bochs, on a acces aux registres et a un tas d'autres choses. Il existe même un front-end graphique : BFE.

[fefe]

c'est là que je me rend compte que je suis vraimetn très mauvais en programmtion

d'ailleurs parfois je me demande si je suis le seul non-codeur du coin...

Je crois que c'est le cas de tout le monde quand tu commences a faire de l'arithmetique binaire le code s'obscurcit tres vite et commence a ressembler plus a du verilog qu'a un language de haut niveau.

[Lissyx]

Avec le debugger de Bochs, on a acces aux registres et a un tas d'autres choses. Il existe même un front-end graphique : BFE.

Confere ce que je disait précédemment, BFE ne semble plus maintenu (dernier tarball de BFE2 daté de 2004 ...).

[Lissyx]

Je crois que c'est le cas de tout le monde quand tu commences a faire de l'arithmetique binaire le code s'obscurcit tres vite et commence a ressembler plus a du verilog qu'a un language de haut niveau.

Si tant est qu'on puisse considérer le C comme un langage de haut niveau.

Certes, par rapport à l'assembleur ...

[Dandu]

c'est là que je me rend compte que je suis vraimetn très mauvais en programmtion

d'ailleurs parfois je me demande si je suis le seul non-codeur du coin...

non non, j'ai *beaucoup* de mal à suivre, même si a une époque je me débrouillai pas mal en assembleur et en C, je ne sais plus faire grand chose.

[Alice]

C'est là que je me rend compte que je suis vraimetn très mauvais en programmtion

rien de bien méchant en fait... Ce n'est que la synthaxe qui est un peu obscure. Le code ne fait qu'ajouter (2^51 + 2^52) a un double. De par la représentation floatante, on obtient sur les 32bits de poids faible la représentation entière du double. Le plus obscur à comprendre c'est le pourquoi du comment.

Si tant est qu'on puisse considérer le C comme un langage de haut niveau.

Pourquoi? il y a plus haut niveau que le C/C++ ? . Le C c'est bon, mangez en. Avec le C tu peux faire tout (et donc n'importe quoi) en ayant une vision du comment sans rentrer dans les entrailles de la bêtes avec de l'asm. Va t'en expliquer à un "codeur" qui n'a fait que du Java ce qu'est un segfault et l'importance de la gestion de la mémoire... Il te regardera d'un air dubitatif en criant haut et fort: "vive le Web2" :???:

[Lissyx]

Pourquoi? il y a plus haut niveau que le C/C++ ? . Le C c'est bon, mangez en. Avec le C tu peux faire tout (et donc n'importe quoi) en ayant une vision du comment sans rentrer dans les entrailles de la bêtes avec de l'asm. Va t'en expliquer à un "codeur" qui n'a fait que du Java ce qu'est un segfault et l'importance de la gestion de la mémoire... Il te regardera d'un air dubitatif en criant haut et fort: "vive le Web2" :???:

J'ai pas dit qu'il fallait jeter le C/C++. Au contraire

[Foudge]

Hey hey... c'était d'ailleur très rigolo! D'ailleurs voilà du code en C qui fait la chose. Une méthode qui converti un double en int32_t et une qui fait la conversion d'un float en uint16_t.

union dblint
{
	int32_t i32;
	int64_t i64;
	double	d;
};

inline int32_t double2Int(double d)
{	
 	dblint tmp;
	
	/* 0x4338000000000000 = (1 << 51) + (1 << 52) */
	tmp.i64 = 0x4338000000000000; 
	tmp.d  += d;		
	
	return tmp.i32;
}

union fluint16
{
	uint32_t i32;
	uint16_t i16;
	float 	 f;
};

inline uint16_t float2Uint16(float f)
{	
	fluint16 tmp;		
	
	/* 0x4B400000 = (1 << 23) + (1 << 22); */
	tmp.i32 = 0x4B400000;	
	tmp.f  += f;
		
	return tmp.i16;
}

Que du bonheur

Aujourd'hui, quant on fait ce genre de conversion via un simple cast, le compilateur utilise-t-il ce genre d'optimisation ?
Cela est-il également le cas en cas de conversion implicite (donc sans cast) ?

[Fanche]

Si tant est qu'on puisse considérer le C comme un langage de haut niveau.

Certes, par rapport à l'assembleur ...

D'une certaine manière le C peut être considéré comme du bas niveau dans la mesure où maintenant ça sert aussi à programmer des fpga non?
"C a tous les niveaux"! :D

[Yasko]

rien de bien méchant en fait... Ce n'est que la synthaxe qui est un peu obscure. Le code ne fait qu'ajouter (2^51 + 2^52) a un double. De par la représentation floatante, on obtient sur les 32bits de poids faible la représentation entière du double. Le plus obscur à comprendre c'est le pourquoi du comment.

Oui, et c'est aussi (surtout) lié à union (partage de l'espace mémoire). Ca aurait été un struct à la place, les 2 fonctions n'auraient jamais rien retourné (puisqu'à aucun il n'y d'affectation directe de i16 ou i32).

Le C c'est bon, mangez en. Avec le C tu peux faire tout (et donc n'importe quoi) en ayant une vision du comment sans rentrer dans les entrailles de la bêtes avec de l'asm. Va t'en expliquer à un "codeur" qui n'a fait que du Java ce qu'est un segfault et l'importance de la gestion de la mémoire... Il te regardera d'un air dubitatif en criant haut et fort: "vive le Web2" :???:

C'est clair. Mais c'est le métier qui veut ça.
Y a 10 ans, dire qu'on est informaticien ne voulait rien dire, aujourd'hui dire qu'on est codeur/développeur ne veut plus rien dire non plus, l'activité est devenue tellement large (notamment entre les devs "bas niveau" et les devs "d'entreprise").
Un developpeur java ne sera pas très à l'aise si il doit produire ou comprendre du code comme celui ci-dessus, mais un developpeur C ne sera peut être pas non plus très à l'aise si il doit se dépatouiller avec Hibernate, JBoss et compagnie (mais la transition devrait quand même être plus facile, quand on est bon en C (ce qui n'est pas mon cas), on est bon en tout , c'est comme math sup/spé qui mène à tout...)

[fefe]

Aujourd'hui, quant on fait ce genre de conversion via un simple cast, le compilateur utilise-t-il ce genre d'optimisation ?
Cela est-il également le cas en cas de conversion implicite (donc sans cast) ?

Les compilo utilisent les instructions de conversion float to int. L'inconvenient de cette methode soft est que tu as besoin de store la donnee et la recharger alors qu'avec une instruction float to int le transfer de donnees ne passe pas par le cache mais de registre a registre (sauf sur K8 ou ca passe par le cache de toutes facons).
Au final tu payes un store fp, un load et ton addition, plutot qu'une inst reg-reg (non pipelinee en general par contre). Si tu as besoin de debit passer par le cache peut eventuellement etre plus performant, mais la plupart du temps c'est la latence qui est recherchee dans ce genre de cas, et c'est 2 a 3 fois plus rapide d'utiliser l'instruction.

Je suppose que les librairies d'emulation font comme ca par contre.

[fefe]

c'est comme math sup/spé qui mène à tout...)

Ah bon ?

[Yasko]

Mène à tout, oui, même au suicide.
Bon OK, tout non, j'exagerais volontairement, mais quand tu es bon en math, tu peux quand même faire beaucoup de chose.
Par exemple, je crois me rappeler que tu as plus de chance d'intégrer une grande école d'économie si tu as fait une terminale S qu'une terminale ES.

[Alice]

Les compilo utilisent les instructions de conversion float to int. L'inconvenient de cette methode soft est que tu as besoin de store la donnee et la recharger alors qu'avec une instruction float to int le transfer de donnees ne passe pas par le cache mais de registre a registre (sauf sur K8 ou ca passe par le cache de toutes facons).
Au final tu payes un store fp, un load et ton addition, plutot qu'une inst reg-reg (non pipelinee en general par contre). Si tu as besoin de debit passer par le cache peut eventuellement etre plus performant, mais la plupart du temps c'est la latence qui est recherchee dans ce genre de cas, et c'est 2 a 3 fois plus rapide d'utiliser l'instruction.

Oui et re-oui. Je l'avais pas précisé mais le code précédent ce n'est que pour illustré ce que disait Franck. A ne pas utiliser en pratique.

[Foudge]

Les compilo utilisent les instructions de conversion float to int.
[...]

Ha ok, il existe des instruction spsécifiques.

Oui et re-oui. Je l'avais pas précisé mais le code précédent ce n'est que pour illustré ce que disait Franck. A ne pas utiliser en pratique.

Ha pardon, j'ai cru qu'il s'agissait de "vraies" optimisations, mais qu'on utilisait il y a 15 ans :ange:

[Neo_13]

rien de bien méchant en fait... Ce n'est que la synthaxe qui est un peu obscure. Le code ne fait qu'ajouter (2^51 + 2^52) a un double. De par la représentation floatante, on obtient sur les 32bits de poids faible la représentation entière du double. Le plus obscur à comprendre c'est le pourquoi du comment.



Pourquoi? il y a plus haut niveau que le C/C++ ? . Le C c'est bon, mangez en. Avec le C tu peux faire tout (et donc n'importe quoi) en ayant une vision du comment sans rentrer dans les entrailles de la bêtes avec de l'asm. Va t'en expliquer à un "codeur" qui n'a fait que du Java ce qu'est un segfault et l'importance de la gestion de la mémoire... Il te regardera d'un air dubitatif en criant haut et fort: "vive le Web2" :???:

Faudrait que je prene 10min pour prendre un papier un crayon et que j'y réfléchisse, mais aujourd'hui, j'ai lutté toute la journée (levé du pied gauche avec le cerveau qui est resté couché, lui, c'est assez difficile), alors un autre jour t1cable:

[Franck@x86]

Les compilo utilisent les instructions de conversion float to int. L'inconvenient de cette methode soft est que tu as besoin de store la donnee et la recharger alors qu'avec une instruction float to int le transfer de donnees ne passe pas par le cache mais de registre a registre (sauf sur K8 ou ca passe par le cache de toutes facons).
Au final tu payes un store fp, un load et ton addition, plutot qu'une inst reg-reg (non pipelinee en general par contre). Si tu as besoin de debit passer par le cache peut eventuellement etre plus performant, mais la plupart du temps c'est la latence qui est recherchee dans ce genre de cas, et c'est 2 a 3 fois plus rapide d'utiliser l'instruction.
Je suppose que les librairies d'emulation font comme ca par contre.

Les compilos font ceci :

#define LONG(L, F)\
_asm { fld dword ptr F}\
_asm { fistp dword ptr L}

à ceci près qu'ils ajoutent un test de débordement systématique, car les deux types n'ont pas les mêmes limites.

Donc finalement cette macro, bien que super peu pratique par rapport à un simple "(int)f", reste le meilleur compromis à mon avis.

[braoru]

..........
Un developpeur java ne sera pas très à l'aise si il doit produire ou comprendre du code comme celui ci-dessus, mais un developpeur C ne sera peut être pas non plus très à l'aise si il doit se dépatouiller avec Hibernate, JBoss et compagnie (mais la transition devrait quand même être plus facile, quand on est bon en C (ce qui n'est pas mon cas), on est bon en tout , c'est comme math sup/spé qui mène à tout...)

Il est clair que de remonter les couches est toujours plus facile que de les descendre . (Vu la morflée que j’ai subi du passage prog delphi et embarqué C à VHDL)