MIPS is back

[Paice]

Je me demande si par hasard Via ne leur en aurait pas refilé une qu'ils auraient récupéré des restes de Cyrix/National Semiconductors.

Ou alors ST en détient une, vu qu'ils ont longtemps fabriqué des Cyrix et qu'il font d'autres proc, et ils en font bénéficier l'ICT, non ?

[Møgluglu]

Je pense plutôt que comme dit Newbie, c'est une extension de jeu d'instruction pour faciliter le travail des JIT X86->MIPS-Godson.

Du coup on passe du hardware au software, et les questions d'IP sont nettement plus floues (brevets logiciels toussa) : depuis quand il faut une licence pour programmer un simu/émulateur/JIT X86?
En tout cas les avocats de Transmeta vont avoir de quoi s'occuper.

[Alexko]

Je pense plutôt que comme dit Newbie, c'est une extension de jeu d'instruction pour faciliter le travail des JIT X86->MIPS-Godson.

De plus, si je ne m'abuse les licences x86 ne sont pas transmissibles...

Du coup on passe du hardware au software, et les questions d'IP sont nettement plus floues (brevets logiciels toussa) : depuis quand il faut une licence pour programmer un simu/émulateur/JIT X86?
En tout cas les avocats de Transmeta vont avoir de quoi s'occuper.

Et puis surtout, si le problème est software, ça ne concerne pas ST Micro mais seulement les Chinois.

[fefe]

Rien n'empeche les chinois de faire du x86 pour leur marche interieur . C'est pas comme si ils etaient habitues a se soucier de details comme des licenses.

Il y a des emulateurs x86 plus vieux que transmeta (genre Bochs) donc transmeta peut s'accrocher por essayer de claim le moindre brevet la dessus en dehors de leurs techniques de power management. Pour le code morphing software, ils le vendent a qui n'en veut pour bien cher, mais je ne pense pas qu'ils cherchent vraiment a depenser des frais de justice pour rien.

Et sinon l'acceleration de 10x de l'emulation ca sent le cas particulier, genre appel systeme ou autre. Les emulateurs x86 bien faits tournant sur une archi risc classique n'ont jamais ete 10x moins performant que le hard natif en moyenne (les emulateurs PC sur mac PPC etaient typiquement 3-4x plus lents dans mes souvenirs, 2x dans certaines conditions).

Bien entendu la lenteur des appels systemes rendait ces systemes emules particulierement non responsifs, ce qui certes merite un bon coup d'optim.

[newbie06]

Un peu plus d'info sur le bidule chinois dans ce thread:

http://realworldtech.com/forums/inde...92525&roomid=2

Pour info, Gabriele Svelto bosse pour ST.

[Yasko]

Around 200 developers are working on the Godson hardware,

C'est beaucoup ?
Ils ont l'air de progresser assez vite (triplement des perfs à chaque nouvelle µarch), enfin, c'est au début que ca va le plus vite.

[Minuteman]

Chez Centaur (ceux qui font les CPU VIA) ils sont 60 pour donner un ordre d'idée, ils font un putain de bon boulot en étant 60 remarque.

[Yasko]

Oui, 200, ca me semble beaucoup.
Je crois me rappeler que pour Atom, ils étaient une quarantaine.

Ceci explique peut être cela...

[fefe]

200 c'est moins que ce que Montalvo avait... Et pas loin de ce que Montalvo avait juste pour bosser sur la compatibilite x86... Donc ce n'est pas tant que ca.

Pour Centaur/Intel c'est completement different de demarrer en ayant un framework de validation tout pret pour le x86, et un design precedent a rafiner (pour Centaur comme pour Intel qui peut recuperer des blocs complexes designes pour d'autres cpus x86).

200 pour faire son premier CPU x86 aujourd'hui c'est assez agressif . Bien sur c'est nettement moins si le machin n'a pas besoin d'etre PC-compatible, mais bon...

[Møgluglu]

ICT acquiert une licence MIPS.

Ça pourrait leur permettre de fabriquer ou faire fabriquer des Loongson en court-circuitant ST...

[newbie06]

J'ai oublié de poster ici Un article intéressant sur le hardware de Godson-3 destiné à accélérar la simu de x86 :

http://iccd.et.tudelft.nl/2009/proceedings/305Hu.pdf

[Møgluglu]

J'ai oublié de poster ici

Je suis très déçu, ça fait une semaine que le lien a été posté sur RWT et qu'on t'attendait .

Un truc que je n'ai jamais compris et qui n'est pas abordé dans l'article, c'est comment on peut arriver à simuler correctement le comportement du X87.
Même en admettant qu'on ne simule que des applis Win32 qui gardent le flag de précision sur double, faut gérer les (absences d')overflows dans les registres, sans parler des exceptions retardées...

À la limite, en activant toutes les exceptions arithmétique et en faisant un rollback complet instruction par instruction en cas d'exception?

Ce qui est sûr c'est que pour émuler les applis Linux i386 c'est mort (calcul flottant en 80-bit).

[newbie06]

Je suis très déçu, ça fait une semaine que le lien a été posté sur RWT et qu'on t'attendait .

C'est parce que j'etais occupe a poster la-bas. Ca me rend dingue, les mecs comprennent pas les difficultes qu'il y a a ecrire un binary translator fonctionnellement correct

Un truc que je n'ai jamais compris et qui n'est pas abordé dans l'article, c'est comment on peut arriver à simuler correctement le comportement du X87.
Même en admettant qu'on ne simule que des applis Win32 qui gardent le flag de précision sur double, faut gérer les (absences d')overflows dans les registres, sans parler des exceptions retardées...

À la limite, en activant toutes les exceptions arithmétique et en faisant un rollback complet instruction par instruction en cas d'exception?

Ce qui est sûr c'est que pour émuler les applis Linux i386 c'est mort (calcul flottant en 80-bit).

Bah ils font comme tout le monde je parie : leur simulation n'est pas precise. Il est quasi-impossible de mapper du FP d'un processeur sur un autre, il y a trop de "details" qui tuent, meme lorsqu'on reste dans le cadre du standard.

Donc soit ta FPU est semantiquement identique et c'est cool, soit elle ne l'est pas et tu as deux solutions : tu acceptes de ne pas simuler a l'identique, tu passes par du soft pour simuler les instructions FP (par exemple, SoftFloat).

[Møgluglu]

C'est parce que j'etais occupe a poster la-bas. Ca me rend dingue, les mecs comprennent pas les difficultes qu'il y a a ecrire un binary translator fonctionnellement correct

Ah c'était toi...

Bah ils font comme tout le monde je parie : leur simulation n'est pas precise. Il est quasi-impossible de mapper du FP d'un processeur sur un autre, il y a trop de "details" qui tuent, meme lorsqu'on reste dans le cadre du standard.

Le X87 est quand-même un cas à part.
Simuler un archi raisonnablement constituée conçue pour être IEEE-compliant dans un environnement IEEE-compliant est tout à fait faisable. À la limite on peut avoir besoin de rajouter des triggers d'exceptions et autres pour les cas où l'implémentation dévie, mais c'est déjà un problème qu'ont les compilateurs pour respecter IEEE-754(2008).

(par exemple, SoftFloat)

Ah oui, ce truc tout lent qui a une norme de retard.

[newbie06]

Le X87 est quand-même un cas à part.
Simuler un archi raisonnablement constituée conçue pour être IEEE-compliant dans un environnement IEEE-compliant est tout à fait faisable. À la limite on peut avoir besoin de rajouter des triggers d'exceptions et autres pour les cas où l'implémentation dévie, mais c'est déjà un problème qu'ont les compilateurs pour respecter IEEE-754(2008).

Mouai, je t'invite a regarder du cote de l'Alpha Et aussi les variantes sur l'encodage des sNaN.

Est-ce que ce truc a déjà servi à autre chose qu'émuler du PowerPC sans Altivec sur du X86?

Oui, QEMU l'utilise.

[Møgluglu]

Mouai, je t'invite a regarder du cote de l'Alpha Et aussi les variantes sur l'encodage des sNaN.

Qu'est-ce qu'il n'est pas possible de faire en activant les exceptions Underflow, Overflow, Denormal et en traitant les cas particuliers en soft (qui n'arrivent pas pour les normaux)?
(i.e., comme le compilateur/OS fait pour pour faire tourner de l'arithmétique IEEE 754 sur Alpha, mais dans l'autre sens)

Oui, QEMU l'utilise.

J'ai ninja-édité (avec un autre commentaire d'aussi mauvaise foi), j'avais confusé avec un autre truc.

En vrai, je suis totalement de mauvaise foi, parce qu'à ma connaissance il n'existe aucune plate-forme qui respecte la norme IEEE 754 actuelle (le Power6 et Fermi doivent être ce qui s'en rapproche le plus).

[newbie06]

Qu'est-ce qu'il n'est pas possible de faire en activant les exceptions Underflow, Overflow, Denormal et en traitant les cas particuliers en soft (qui n'arrivent pas pour les normaux)?

Attention, je ne suis pas un specialiste du FP, donc je dis peut-etre des aneries.

Mettons que les signaling NaN se distinguent par un seul bit des quiet. Mon processeur simule fait un load d'un sNaN stocke en memoire et donc il s'attend a une exception.

Pas de bol, la machine sur laquelle je simule voit ca comme un qNaN, donc pas d'exception generee.

Et voila, on a une difference de comportement.

EDIT: si tu as mieux que SoftFloat, je suis preneur, surtout si ca a la bonne license

[Møgluglu]

Attention, je ne suis pas un specialiste du FP, donc je dis peut-etre des aneries.

Non, tu as raison. En plus, ça arrive effectivement en pratique avec l'Alpha, qui doit trapper aussi sur les QNaN (pour pouvoir appeler un handler qui émulera le comportement IEEE...)

(Après, si on n'émule que des applis en mode user qui ne touchent pas à l'environnement FPU, on doit pouvoir encore arriver à court-circuiter le tout... Au risque d'introduire un tas de bugs.)

EDIT: si tu as mieux que SoftFloat, je suis preneur, surtout si ca a la bonne license

Mes potes/tes concurrents ont un truc 2 à 6 fois plus rapide que d'autres trucs basés sur SoftFloat, mais c'est prévu pour l'embarqué sur processeurs sans FPU plutôt que pour de la simulation, et c'est sous LGPL...

Sinon NVidia a une bibliothèque superbement précise mais archi-lente pour leur archi sous une vague licence open-source maison :
ftp://download.nvidia.com/CUDAOpen64/mob64.tar.gz
(non, les numéros d'opcodes ne correspondent ni à Tesla ni à Fermi, j'ai vérifié )