Intel devrait lancer sa neuvième génération de puces Core le premier octobre, Réactions à la publication du 13/08/2018

[radamanthys]

Si on pousse ta logique jusqu'au bout on en reviendrait a un cpu avec moins de coeurs (coeurs logiques en tout cas), et une fréquence plus élevée ...
Ca rappel un certain pentium 4 avec son architecture netburst qui devait atteindre les 10 GHz, et on se rappel ce que ca a donné.
Donc désolé mais je ne suis pas très convaincu.

[iAPX]

Si on pousse ta logique jusqu'au bout on en reviendrait a un cpu avec moins de coeurs (coeurs logiques en tout cas), et une fréquence plus élevée ...
Ca rappel un certain pentium 4 avec son architecture netburst qui devait atteindre les 10 GHz, et on se rappel ce que ca a donné.
Donc désolé mais je ne suis pas très convaincu.

Le Pentium-4 avait pourtant l'hyperthreading et le dual-core, tu te trompes de cible

Je ne parle pas de fréquence plus élevées per-se, avec une architecture avec un pipeline plus long, cas du Pentium-4 où l'hyperthreading était indispensable pour compenser ses erreurs de prédictions et de prefetching, n'arrivant pas à remplir son pipeline correctement et donc passant une grosse part de son temps à attendre. Tout l'inverse!

Je parle de micro-architecture simplifiée, coté decoder et scheduler en enlevant l'hyper-threading, permettant alors dans le même budget thermique et de consommation de monter plus haut en fréquence, puisque nos CPU actuelles sont essentiellement limitées par leur alimentation (notamment lors des pointes de fréquence sur des tâches interactives) et aussi par les capacités de dissipation thermique sur les tâches longues.
Avec un avantage immédiat en performance mono-thread, mais aussi possiblement une aussi bonne performance en multi-thread (avec plus de cœurs dans le même TDP) car l'Hyperthreading n'est pas nécessairement gagnant en perf/Watt car il augmente énormément la complexité, je dirais de manière exponentielle au fur et à mesure que nos core se complexifient eux-même.

La simplification permettrait alors un gain en fréquence en sus d'un gain probable en IPC, surtout en mono-thread, permettant un gros gain en perf dans ce cas.
On s'apercevra alors que l'hyperthreading est moins utile, et qu'à TDP identique, un Core i7 6c/12t sera plus lent qu'un Core i7 8c/8t, tant en mono-thread qu'en multithread (moins largement) à cause de la simplification des coeurs et des ressources disponibles par thread supérieurs (caches, prédicteurs, registres physiques, etc).

C'est mon hypothèse

[Ambroise]

Maintenant la FPU s'éteint sur un Core quelque-chose?

Mis à part les unités AVX2 ou AVX-512, non, il n'y a rien qui s'éteint (et ce ne sont pas des unités FPU mais des unités vectorielles fp+int).

Cela paraît tendancieux de différencier FPU et unités AVX sur les x86-64. Le calcul flottant est nécessairement du calcul vectoriel sur un x86-64 : il n'y a pas de registres flottants, uniquement des registres vectoriels encodant des flottants.
Donc oui, si les unités vectorielles peuvent être arrêtées alors les FPUs peuvent être arrêtés.

[SartMatt]

Je pense sincèrement qu'Intel est en train de sortir de l'hyper-threading, s'en servant pour segmenter comme tu l'écris aussi (donc avec des bonds de TDP entre 4c/4t et 4c/8t, idem pour 6c ou 8c)

Sauf que non.
Il n'y a pas de bon de TDP entre les gammes nc/nt et nc/2nt. Les bons de TDP se font quand il y a ajout de cœurs ou montée en fréquence. Par exemple, les Core i5-8600 et 8600K 6c/6t sont à 65 et 95W. Tout comme les i7-8700 et 8700K en 6c/12t.
Et les futurs i7-9700K 8c/8t et i9-9900K 8c/16t sont tous les deux donnés pour 95W également.
Idem plus bas dans la gamme, le 2c sont à 54W en version standard et 35W en version T, aussi bien dans la gamme Celeron (2c/2t) que dans la gamme Pentium (2c/4t), et c'est en ajoutant des cœurs pour passer aux i3 (4c/4t) que le TDP augmente (65W et même 91W pour le 8350K).

Bon après, faut dire aussi que ces bons de TDP, c'est pas franchement de la technique non plus. C'est, là encore, du marketing pour segmenter la gamme. D'où par exemple les TDP supérieurs à 90W de tous les modèles K, alors qu'ils pourraient largement être en dessous : il s'agit là de laisser une bonne marge pour l'overclocking.

Dans cette optique, les Core i3 et i5 Desktop qui constituent le gras de ce marché sont très significatifs avec l'absence d'hyperthreading, Intel ayant pu orienter sa gamme autour de l'hyperthreading (avec des exceptions sans), mais son cœur de gamme sera sans hyperthreading maintenant.

Un cœur de gamme desktop sans HT, c'est pas spécialement nouveau non plus, donc ce n'est pas vraiment un argument en faveur de la thèse de l'abandon de l'HT hein... Les Core i5 desktop n'ont jamais eu l'HT (jamais jamais, ça a toujours été la grosse différence entre les i5 et les i7, ça et le cache, sur certains générations il n'y avait même pas de différences de fréquences).

Quand aux i3, en 8 générations ils n'ont eu droit à l'HT que deux fois, le temps de faire la transition de 2 vers 4 cœurs.

Avec une micro-architecture non-HT simplifiée pour ce cœur de gamme (et non désactivé) je m'attend à des performance mono-thread très accrues, justement pour creuser l'écart grâce à un Turbo plus agressif en mono-thread n'ayant pas de "gras" à trainer inutile dans ce cas sur chaque core.

Tu peux toujours attendre alors je crois ^^

T'es bien le seul à parler d'une nouvelle micro-architecture sans HT... La réalité semble plutôt même être pas de nouvelle µarch du tout, la 9ème génération n'est rien d'autre qu'un "refresh" du Coffee Lake S de la 8ème. À tel point d'ailleurs que le microcode est le même : les noms de ces CPU sont déjà mentionnés dans la doc des update de microcode, et on y voit que les 9xxx partagent le même CPUID/Platform ID que les 8xxx équivalents. Donc la carte mère leur enverra strictement le même microcode.

Le i7-9700K n'apparait pour sa part pas là dedans aux côtés des 8xxx (forcément, ce n'est pas un Coffee Lake 6+2, c'est un 8+2), mais je suis prêt à parier qu'il aura le même CPUID/Platform ID que le i9-9900K. Ça n'aurait aucun sens de faire un cœur sans HT spécifique à ce modèle sans l'utiliser aussi sur les i5 6c et les i3 4c eux aussi dépourvus de l'HT...

Ce message a été modifié par SartMatt - 13 Aug 2018, 23:14.

[iAPX]

Maintenant la FPU s'éteint sur un Core quelque-chose?

Mis à part les unités AVX2 ou AVX-512, non, il n'y a rien qui s'éteint (et ce ne sont pas des unités FPU mais des unités vectorielles fp+int).

Cela paraît tendancieux de différencier FPU et unités AVX sur les x86-64. Le calcul flottant est nécessairement du calcul vectoriel sur un x86-64 : il n'y a pas de registres flottants, uniquement des registres vectoriels encodant des flottants.
Donc oui, si les unités vectorielles peuvent être arrêtées alors les FPUs peuvent être arrêtés.

Le calcul flottant n'est pas du tout nécessaire pour du vectoriel sur x86-64 (mieux nommé AMD64), et certainement pas avec les unités AVX2 ou AVX-512, renseigne-toi

Pour le reste on verra bien, mais des core sans Hyperthreading (donc simplifié uniquement de ce point-de-vue) ne sont pas réellement une micro-architecture différente, ils fonctionneront exactement comme si l'Hyperthreading était désactivé, mais avec moins de transistors actif, donc potentiellement plus rapides dans les mêmes enveloppes énergétiques et thermiques.
(et accessoirement un coût de production plus bas dû à la simplification decoder+scheduler et l'ensemble, par occupation de moins de surface sur le Wafer avec en bonus une baisse du taux de rejets)

Ce message a été modifié par iAPX - 14 Aug 2018, 00:01.

[SartMatt]

Cela paraît tendancieux de différencier FPU et unités AVX sur les x86-64. Le calcul flottant est nécessairement du calcul vectoriel sur un x86-64 : il n'y a pas de registres flottants, uniquement des registres vectoriels encodant des flottants.

Il n'y a plus la pile de registres flottants ST0 à ST7 de la FPU x87 ?

(et accessoirement un coût de production plus bas dû à la simplification decoder+scheduler et l'ensemble, par occupation de moins de surface sur le Wafer avec en bonus une baisse du taux de rejets)

Au contraire, avoir une version spécifique pour les sans HT plutôt que d'utiliser une version avec HT désactivé, ça fait augmenter les taux de rejets.

Parce que tu peux être certain qu'Intel a prévu un design qui lui permet de choisir après fabrication quel sera le pipeline qui sera désactivé.

Ainsi, s'il y a un défaut qui affecte un des pipelines d'un modèle avec HT, ils en font un modèle sans HT en désactivant complètement ce pipeline. C'est une forme de redondance finalement...

Avec un design spécifique sans HT, tu perds cette possibilité de "sauver" une partie des puces défectueuses.

[iAPX]

@SartMatt quelles sont tes statistiques ou résultats d'étude?

Il faut combattre les Fake News

Parce que moins de transistor = moins de taux de rejets à process identique, là c'est factuel.
Et je m'en voudrais que tu écrives des choses illégales

PS tu as évidemment raison que les registres de la FPU existent encore, logiquement partagés avec les registres MMX sur certains anciennes micro-architectures (MMX n'est plus supporté depuis bezef, un Amd64 actuel n'est donc pas compatible donc avec une CPU x86 même en mode 32 bits).
Plus précisément, Intel a laissé tomber la compatibilité 32bits avec les Core™2 et antérieurs (jusqu'au Pentium MMX) sur les Core™2 Penryn. Ça devrait faire réfléchir quand on parle de "compatibilité" x86

Ce message a été modifié par iAPX - 14 Aug 2018, 21:32.

[SartMatt]

@SartMatt quelles sont tes statistiques ou résultats d'étude?

Et les tiennes, mon cher ?

Dans les puces Intel actuelles, le gros de la surface de la puce, c'est le cache et l'IGP. Donc supprimer l'HT, ça va pas forcément faire gagner des masses de place, donc pas forcément changer énormément le taux de rejet. Par contre une puce rejeté a 100% de chances d'être perdue, alors qu'avec un schéma incluant systématiquement l'HT il y a une chance que la puce rejetée avec HT puisse être commercialisée sans HT. Ajoute à ça le coût forcément plus élevé qu'il y a à avoir deux µarch différentes, et au final c'est sans doute pas une stratégie rentable.

D'ailleurs, si ta théorie était juste, on se demande bien pourquoi Intel n'a jamais opté pour cette approche plus rentable jusqu'à présent, alors que dans leur gamme il y a toujours eu cohabitation entre des puces avec et sans HT depuis qu'ils ont sorti l'HT, sauf à l'époque des C2D où ils y avaient temporairement renoncé.


Tiens juste histoire de se faire une idée du coût en transistors de l'HT. Entre le Pentium 4 Willamette et le Pentium 4 Northwood (premier CPU Intel avec HT), le nombre de transistors est passé de 42 à 55 millions. Sachant que le cache est passé dans le même temps de 256 Ko à 512 Ko et que 256 Ko de SRAM 6T ça fait 12.9 millions de transistors...

(MMX n'est plus supporté depuis bezef, un Amd64 actuel n'est donc pas compatible donc avec une CPU x86 même en mode 32 bits).
Plus précisément, Intel a laissé tomber la compatibilité 32bits avec les Core™2 et antérieurs (jusqu'au Pentium MMX) sur les Core™2 Penryn. Ça devrait faire réfléchir quand on parle de "compatibilité" x86

Euh... Tu sors ça d'où pour l'abandon du MMX ?
Mon i7-6700K indique bien qu'il supporte le MMX quand on lui demande les jeux d'instructions qu'il gère :


Et j'arrive sans problème à lancer le jeu POD via pod_mmx.exe (qui ne marchait pas du tout à l'époque sur les Pentium non MMX).
La liste des errata de la 8ème génération confirme également le support du MMX, puisqu'elle mentionne un dysfonctionnement du mode debug (des breakpoints qui sont ignorés) dans certains cas d'utilisation des instructions MMX (errata n°34).
Tu confondrais pas avec le 3DNow, qu'AMD a abandonné en 2010 ?

Quand à la compatibilité avec les puces antérieures au C2D, je sais pas ce que tu entends pas là, mais je peux t'assurer que j'utilise encore tous les jours sur des puces Core 6ème, 7ème et 8ème génération des binaires 32 bits qui ont été compilés pour des CPU largement antérieurs au C2D... Il y en a même qui s'amusent à booter nativement des Windows 9x sur des Core i, ça ne présente aucune difficulté particulière...

Alors peut-être qu'Intel a cessé de garantir la compatibilité (mais en même temps, je vois pas trop comment, vu que le jeu d'instructions reste le même... ne pas être compatible, ça implique que le CPU est non conforme à ses propres spécifications, puisque Intel n'inclus pas le jeu d'instruction dans les spécifications des CPU, le jeu d'instruction est documenté à part, de manière commune à tous les CPU, la même doc de jeu d'instruction couvre aujourd'hui toute la gamme Intel du Pentium jusqu'au Core, mais fait également quelques références aux puces pré-Pentium, y compris les puces 16 bits), mais dans les faits, elle est toujours là.

La version actuelle de la doc du jeu d'instruction (datant de 2016) est d'ailleurs on ne peut plus claire sur la rétrocompatibilité totale : "Object code created for processors released as early as 1978 still executes on the latest processors in the Intel 64 and IA-32 architecture families.".

Ce message a été modifié par SartMatt - 14 Aug 2018, 23:01.

[iAPX]

...
La version actuelle de la doc du jeu d'instruction (datant de 2016) est d'ailleurs on ne peut plus claire sur la rétrocompatibilité totale : "Object code created for processors released as early as 1978 still executes on the latest processors in the Intel 64 and IA-32 architecture families.".

On va faire court pour démontrer le coté Fake News de ce que tu écris et cette inanité d'expression: iAPX 286 LOADALL (Ox0F05 in "Object code created...") n'est pas supporté par le 80386 (ni DX, ni SX ni SLC, un 486 déguisé, ni suivants). Intel ment effrontément et tu choisis de croire cette multinationale. Point final.

Je viens de relire ce que Intel a écrit et j'ai beaucoup ri "Object code created for processors released as early as 1978 still executes on the latest processors in the Intel 64 and IA-32 architecture families." veut juste dire que le code des iAPX 86 s'exécute sur les CPU actuelles (pas celui des iAPX88, encore moins iAPX 186 ou iAPX286 et suivants). Intel n'assure pas une compatibilité ascendante, juste que du code 16-bits d'iAPX 86 s'exécute correctement sur une CPU actuelle, avec aucune garantie pour les CPU intermédiaires. Du piratage social dans cette déclaration

Intel ment par omission, et tu plonges dedans...

0 compatibilité depuis le début et j'ai d'autres exemples, même en restant dans le monde 32 bits, sans aborder les divers jeux d'instructions 64bits Amd64 vs x86-64 (la guerre!)

Ce message a été modifié par iAPX - 15 Aug 2018, 01:50.

[SartMatt]

Tiens, silence soudain sur le MMX, et aucune réponse sur ce que signifie "Intel a laissé tomber la compatibilité 32bits avec les Core™2 et antérieurs (jusqu'au Pentium MMX) sur les Core™2 Penryn"

On va faire court pour démontrer le coté Fake News de ce que tu écris et cette inanité d'expression: iAPX 286 LOADALL (Ox0F05 in "Object code created...") n'est pas supporté par le 80386 (ni DX, ni SX ni SLC, un 486 déguisé, ni suivants). Intel ment effrontément et tu choisis de croire cette multinationale. Point final.

Parler de fake news ("fake news", c'est un peu le nouveau point godwin pour les mecs en manque d'arguments hein...) après avoir prétendu que le MMX est abandonné depuis le passage au 64 bits, alors que le moindre utilitaire genre CPU-Z prouve le contraire, fallait l'oser

Et là c'est encore toi qui fait dans la "fake news" : LOADALL est une instruction non documentée, elle ne fait pas partie de l'IA-32. Elle a effectivement existé sur certains CPU x86, mais comme elle ne fait pas partie de l'IA-32 elle n'a pas a être utilisée si on veut faire du code qui cible les CPU IA-32 et pas spécifiquement le 80286 ou spécifiquement le 80386 (l'un ou l'autre, car l'instruction n'est pas la même sur les deux modèles).

Bientôt tu vas nous dire que la compatibilité est pas assurée parce que les CPU AMD récents ne répondent plus "Hammer Time" quand on fait un CPUID dessus avec une certaine valeur dans EAX

Je viens de relire ce que Intel a écrit et j'ai beaucoup ri "Object code created for processors released as early as 1978 still executes on the latest processors in the Intel 64 and IA-32 architecture families." veut juste dire que le code des iAPX 86 s'exécute sur les CPU actuelles (pas celui des iAPX88, encore moins iAPX 186 ou iAPX286 et suivants).

"As early as", ça ne veut pas dire "only from". Et pour info le 8088, c'était strictement identique au 8086 à l'exécution.

0 compatibilité depuis le début

N'empêche que dans les faits, perso je ne suis pas encore tombé une seule fois sur un binaire qui refuse de s'exécuter sur une machine récente. Et pourtant, j'en ai fait tourner un paquet des vieux binaires, j'ai même toujours dans un coin des VM avec des vieux OS (jusqu'à Win 3.11) dans cette optique (et VMWare n'assure pas de transcodage si jamais des instructions avaient disparu hein...).

D'ailleurs, même les binaires 3DNow ils tournent bien aujourd'hui s'ils ont été compilés correctement : dès qu'on utilise des instructions qui ne font pas partie du jeu d'instructions de base, il faut utiliser CPUID pour vérifier le flag correspondant à cette instructions, et s'il n'est pas là il faut passer par du code alternatif se passant de cette instruction. Beaucoup de binaires utilisant des extensions du jeu d'instructions sont sans doute mal faits et plantent si l'extension n'est pas là, surtout des binaires récents utilisant des vieilles extensions comme le MMX et le SSE1 (et ce n'est pas un problème pour la rétrocompatibilité des CPU, puisque ces jeux d'instructions sont toujours présents), mais dans le cas de 3DNow, comme il n'a jamais percé, c'est à peu près toujours géré proprement.

sans aborder les divers jeux d'instructions 64bits Amd64 vs x86-64 (la guerre!)

Ces jeux d'instructions sont des extensions. La compatibilité avec un binaire nécessitant une extension est assurée lorsque le CPU supporte ces extensions.

AMD64 et Intel64/EM64T, même s'ils ont énormément d'instructions en commun, sont bien implémentés comme deux extensions différentes, et donc différentiables au niveau de CPUID. Idem pour les variantes AMD des autres extensions (AMD n'a par exemple pas le MMX mais un MMX+, avec quelques instructions supplémentaires, ou encore deux instructions SSE supplémentaires, le SSE4a).

[iAPX]

Je le remets: "Object code created for processors released as early as 1978 still executes on the latest processors in the Intel 64 and IA-32 architecture families."
Le code "0x0F05" du LOADALL du 80286 n'est pas exécutable sur un 80386 dans le même mode, c'est un autre op-code sur le 80386. Pas de compatibilité binaire entre eux.

1978 c'est le 8086 pas le 8088, et il y a des différences à l'exécution rendant ce second incompatible dans certains cas, principalement à cause de son pre-fetcher revu qui fonctionne différemment (problème sur du code se modifiant lui-même, une technique très utilisée dans les années 70 et 80), : ils exécutent les mêmes instructions, mais pas de la même façon

Intel assure la compatibilité avec du code aussi ancien que les CPU sorties en 1978 (iAPX 86 donc), mais n'assure en aucun cas la compatibilité totale entre les CPU plus récentes (iAPX 88 et suivants) jusqu'aux actuelles.

PS: pour MMX mon erreur, c'est l'implémentation de MMX avec SSE2 et l'accès aux registres XMM qui a été arrêté à partir de SSE4 (incompatibilité là encore).

Ce message a été modifié par iAPX - 15 Aug 2018, 12:05.

[SartMatt]

On simplifie, le code "0x0F05" du LOADALL du 80286 n'est pas exécutable sur un 80386 dans le même mode, c'est un autre op-code sur le 80386. Pas de compatibilité binaire entre eux.

La compatibilité binaire est assurée avec le code conforme à la spécification IA-32, qui est la spécification logicielle de référence des CPU Intel (il n'y a aucune autre spécification logicielle pour les CPU Intel... ils ont une spécification matérielle, propre à chaque famille, voire modèle, et une spécification logicielle commune, le "Intel 64 and IA-32 Architectures Software Developer’s Manual"). LOADALL n'est PAS une instruction de l'architecture IA-32.

C'est comme avec une API logicielle. Si tu utilises une fonction que tu as trouvée dans la lib mais qui n'est pas dans la doc et que dans une version ultérieure de la lib cette fonction a disparu, tu peux pas pour autant prétendre que l'éditeur n'a pas assuré la rétrocompatibilité de la nouvelle lib avec le code fait pour l'ancienne... Tu as joué en utilisant une fonction non documenté, tu as perdu. Mais l'éditeur, il a fait son job : ce qui a été implémenté conformément à la documentation de l'ancienne lib marche avec la nouvelle.

PS: pour MMX mon erreur, c'est l'implémentation de MMX avec SSE2 et l'accès aux registres XMM qui a été arrêté à partir de SSE4 (incompatibilité là encore)

Et là encore, il s'agit d'une fonctionnalité non documentée. Si on suit la doc, il faut copier les données des registres XMM vers les registres MMX pour les utiliser avec les instructions MMX. Le SSE2 a justement introduit des instructions dédiées à cette recopie (MOVQ2DQ, MOVDQ2Q).

Encore une fois, si on ne suit pas la documentation, faut pas se plaindre d'avoir ensuite des choses qui ne fonctionnent pas comme on s'y attend

C'est comme si tu t'amuses à utiliser les registres XMM16 à XMM31 avec des instructions SSE. Techniquement le CPU ne te l'interdit pas, mais après faudra pas t'étonner que ton code marche pas sur des CPU ayant le SSE mais pas l'AVX-512... Si tu suis la doc sur l'utilisation de SSE, les registres à utiliser sont les registres XMM0 à XMM7 si le CPU n'est pas en mode 64 bits, et jusqu'à XMM15 s'il est en mode 64 bits, rien d'autre.

Ce message a été modifié par SartMatt - 15 Aug 2018, 12:43.

[iAPX]

...

Tu as cité Intel, qui ne parle pas de Documentation ou de Spécifications mais bien "Object code".

Et il y a des incompatibilités nombreuses qui n'empêchent pas du code générique de s'exécuter, mais posent des problèmes dès que l'on veut exploiter certaines micro-architecture à 100%.

Un autre exemple avec IBTS et XBTS supporté sur le 80386, mais juste les premiers
(Et lit le gag en bas sur leurs op-code avec le 80486 et son propre changement d'opcode pour CPMXCHG!)

Ce message a été modifié par iAPX - 15 Aug 2018, 12:57.

[SartMatt]

...

Tu as cité Intel, qui ne parle pas de Documentation ou de Spécifications mais bien "Object code".

Et ils disent ça dans le cadre d'une documentation, qui décrit les instructions et leur code binaire justement. Dans une telle documentation, il est évident que "object code" fait référence au code tel qu'il est décrit dans la documentation. Et l'instruction LOADALL n'y est PAS décrite.

Un autre exemple avec IBTS et XBTS supporté sur le 80386, mais juste les premiers

Le même site précise que ces instructions étaient non documentées : https://www.pcjs.org/pubs/pc/reference/intel/80386/

(Et lit le gag en bas sur leurs op-code avec le 80486 et son propre changement d'opcode pour CPMXCHG!)

Bien, tu as fini par trouver un vrai exemple d'incompatibilité sur une instruction documentée, qui touche quelques exemplaires de 80486 commercialisés pendant quelques mois (le stepping B0 est arrivé la même année que le stepping A0, donc quelques mois d'écart seulement entre les deux) sur les cinq ans de vie commerciale du 486.

Ça date quand même de pas loin de 30 ans hein... Et si ça se trouve, ça a fait l'objet d'un errata à l'époque pour signaler aux développeurs de ne pas utiliser cette instruction dans sa version "stepping A".

Pour la petite histoire, la raison de ce changement d'opcode semble être liée à l'utilisation des instructions non documentées du 80386 par certains développeurs pour tester les CPU 386 et déterminer s'ils étaient un stepping A ou un stepping B, mais du coup avoir une autre instruction avec le même opcode sur le 486 faisait que ces CPU étaient détectés comme des 386 A... Si les gens se limitaient à utiliser les instructions documentées, il n'y aurait pas eu de problème... L'instruction CPUID est arrivée plus tard pour répondre à ce besoin d'identifier le modèle de CPU et ce dont il est capable.

Ce changement d'opcode a donc sacrifié quelques processeurs pour assurer justement une meilleure compatibilité avec le code écrit pour les CPU plus anciens. Ce n'est donc pas une rupture de rétrocompatibilité, mais au contraire, un moyen de la maximiser.

Ce message a été modifié par SartMatt - 15 Aug 2018, 13:31.

[iAPX]

Comme on devrait le savoir, une seule exception suffit pour invalider une règle...

"Object code created for processors released as early as 1978 still executes on the latest processors in the Intel 64 and IA-32 architecture families."
Est vrai: le code de l'iAPX 86 de 1978 s'exécute encore sur des CPU actuelles, et il n'y a pas de garantie dans cette phrase pour les architectures intermédiaire.

Et avec des exceptions portant sur du code binaire "Object code", incluant au moins une instruction documentée, entre générations et même au sein d'une même génération, on ne peut plus parler de compatibilité binaire, juste de compatibilité partielle.

[SartMatt]

Et avec des exceptions portant sur du code binaire "Object code", incluant au moins une instruction documentée, entre générations et même au sein d'une même génération, on ne peut plus parler de compatibilité binaire, juste de compatibilité partielle.

Avec une exception en 30 ans, il est largement exagéré de parler de "partielle" (qui a une connotation plus "large"), surtout quand la raison même de cette exception a été d'assurer une meilleure compatibilité...

En est en tout cas très loin du manque de compatibilité que laissaient entendre tes propos initiaux parlant d'abandon du MMX et affirmant que "Intel a laissé tomber la compatibilité 32bits avec les Core™2 et antérieurs (jusqu'au Pentium MMX) sur les Core™2 Penryn. Ça devrait faire réfléchir quand on parle de "compatibilité" x86"...

La réalité dans la vraie vie, c'est qu'il faut se lever de bon matin pour trouver un programme (et je dis bien dans la vraie vie, pas un programme écrit spécifiquement pour planter sur les CPU récents, en profitant des errata ou des instructions non documentées hein) x86 qui ne soit pas compatible avec un CPU x86 d'aujourd'hui alors qu'il marchait avec un modèle plus ancien, autrement que par choix de celui qui a compilé le programme (par exemple, si un développeur fait le choix de créer un binaire dépendant du SSE4a sans branche alternative dans le code binaire, c'est normal qu'il ne fonctionne pas sur un CPU Intel...).

Et tout ça, ça montre qu'il y a une vraie volonté de rétrocompatibilité. Ce qui dans le monde informatique actuel, où de plus en plus souvent la pérennité d'un produit n'est pas assurée ou delà de 2-3 ans, si ce n'est moins, ça mérite quand même d'être salué.

Ce message a été modifié par SartMatt - 15 Aug 2018, 13:57.

[iAPX]

...
Et tout ça, ça montre qu'il y a une vraie volonté de rétrocompatibilité. Ce qui dans le monde informatique actuel, où de plus en plus souvent la pérennité d'un produit n'est pas assurée ou delà de 2-3 ans, si ce n'est moins, ça mérite quand même d'être salué.

Je suis d'accord avec cette partie, mais pas la précédente

Écrivant en assembleur depuis les années 70 pour avoir du code totalement optimisé, les incompatibilités des uns et des autres m'ont régulièrement compliqué inutilement la vie, avec comme première rencontrée ls NEC NSC800 en principe compatible avec le Z80 mais dans les faits buggés sur les instructions de répétition (expliquant pourquoi je n'en avais étrangement pas trouvé en désassemblant le Basic Microsoft du Canon X-07).

On ne s'attend pas à devoir recoder des parties optimisées pour qu'elles fonctionnent sur une génération ultérieure, surtout que j'aime encore "jouer" avec des registres AVX2 ou AVX-512 pour charger des données binaires qui ne sont en rien des vecteurs pour les utiliser comme cache (en évitant de surcharger les registres Amd64 virtuels) avec garantie de lecture et d'écriture atomique sur les lignes de cache. Non-orthodoxe mais parfaitement fonctionnel et incroyablement efficace.

[SartMatt]

On ne s'attend pas à devoir recoder des parties optimisées pour qu'elles fonctionnent sur une génération ultérieure, surtout que j'aime encore "jouer" avec des registres AVX2 ou AVX-512 pour charger des données binaires qui ne sont en rien des vecteurs pour les utiliser comme cache (en évitant de surcharger les registres Amd64 virtuels) avec garantie de lecture et d'écriture atomique sur les lignes de cache. Non-orthodoxe mais parfaitement fonctionnel et incroyablement efficace.

À partir du moment où tu fais des choses non documentées, tu ne peux t'en prendre qu'à toi même si ça ne marche plus dans le futur.

Si tu veux de la compatibilité, l'optimisation doit se faire dans les limites de ce qui est décrit dans la doc. Typiquement, pour l'exemple donné plus haut du MMX, la doc dit que l'opérande des instructions MMX est mm/m64, donc soit un registre MMX soit l'adresse d'une donnée 64 bits en mémoire. Si tu met un autre registre et que le CPU ne le bloque pas, ça ne veut pas dire que ça marchera forcément plus tard. C'est un cas non documenté, donc qui peut changer d'une implémentation à l'autre.

Idem avec les registres AVX. Si tu passes un YMM ou un ZMM à une instruction dont la documentation ne précise pas qu'elle accepte un de ces registres, ça peut éventuellement marcher. Mais ça ne marchera pas forcément dans le futur. Et ça implique aussi que, même si l'instruction n'est pas une instruction AVX, tu es censé tester le support AVX avec CPUID avant...


Alors bien sûr, pour éviter ce genre d'incompatibilités dues a des usages non documentés Intel pourrait faire en sorte que seuls les usages documentés soient possibles. Mais au final, ça n'arrangerait sans doute personne : ça complexifierait les CPU, ça dégraderait peut-être même leurs performances, et ça emmerderait ce qui profitent de ce laxisme pour pousser un peu plus loin l'optimisation. Le seul avantage que ça pourrait éventuellement avoir, c'est peut-être une légère réduction du risque de failles de sécurité (mais en contrepartie, une augmentation du risque de bug/errata...).

[Baradal]

Nouvelle génération déjà infectée ?
https://www.lesechos.fr/tech-medias/hightec...lle-2198058.php

[zero]

J'ai jamais compris pourquoi ils font des instructions inutiles (non documentées et déconseillées).
Ils aiment perdre du temps ?

[SartMatt]

J'ai jamais compris pourquoi ils font des instructions inutiles (non documentées et déconseillées).
Ils aiment perdre du temps ?

Ce n'est pas parce que c'est non documenté que c'est inutile.

Je vois au moins trois raisons possibles, mais il y en a sans doute d'autres :
1) Une instruction qui sert en interne chez Intel, par exemple lorsqu'ils testent les CPU en sortie de chaîne de fabrication. Typiquement, je pense que c'était le cas de LOADALL, qui permet de récupérer des informations sur l'état interne du CPU, dont un programme "normal" n'est pas censé avoir besoin.
2) De nouvelles instructions qui ne sont pas encore totalement prêtes,
3) Des nouvelles instructions dont on se rend compte au dernier moment qu'elles exploitent un brevet tiers, alors qu'il est déjà trop tard pour les retirer complètement du CPU (bon ça sur un CPU moderne ça doit pouvoir se retirer via mise à jour du microcode, mais sur les vieux CPU le microcode n'était pas upgradable après fabrication... chez Intel le microcode ne peut être mis à jour qu'à partir du Pentium Pro par exemple).

[zero]

Ce n'est pas parce que c'est non documenté que c'est inutile.

Si puisque, ils disent eux-même de ne pas les utiliser. Tu le fais remarquer toi-même à iAPX.

1) Une instruction qui sert en interne chez Intel, par exemple lorsqu'ils testent les CPU en sortie de chaîne de fabrication. Typiquement, je pense que c'était le cas de , qui permet de récupérer des informations sur l'état interne du CPU, dont un programme "normal" n'est pas censé avoir besoin.

Impossible puisque ces instructions varient d'un CPU à l'autre. LOADALL est un cas très particulier.

2) De nouvelles instructions qui ne sont pas encore totalement prêtes,
3) Des nouvelles instructions dont on se rend compte au dernier moment qu'elles exploitent un brevet tiers, alors qu'il est déjà trop tard pour les retirer complètement du CPU (bon ça sur un CPU moderne ça doit pouvoir se retirer via mise à jour du microcode, mais sur les vieux CPU le microcode n'était pas upgradable après fabrication... chez Intel le microcode ne peut être mis à jour qu'à partir du Pentium Pro par exemple).

Là aussi c'est peu crédible car certaines intructions restent sur plusieurs versions, parfois elles varient, elles disparaissent et reviennent plus ou moins pareil. Souvent aussi, les instructions non documentées sont des instructions similaires à d'autres qui agissent sur des registres différents. Certaines seraient parfois bien utiles même. On dirait plutot qu'ils avancent à taton et n'osent pas se décider.

(Et je ne parle pas que d'Intel.)

Ce message a été modifié par zero - 16 Aug 2018, 03:34.

[SartMatt]

Ce n'est pas parce que c'est non documenté que c'est inutile.

Si puisque, ils disent eux-même de ne pas les utiliser. Tu le fais remarquer toi-même à iAPX.

Et alors ? Ce n'est pas parce qu'ils disent aux utilisateurs de ne pas les utiliser que ça n'est pas utile pour eux. Pour des tests, pour du diagnostic... C'est peut-être également utilisé par le chipset lors de ses communications avec le CPU.

C'est comme tous les produits électroniques qui ont des connecteurs de diagnostic, cachés ou non, mais non documentés (typiquement, le micro USB des Apple TV ou le connecteur planqué derrière la fixation du bracelet sur les Apple Watch). Ce n'est pas parce qu'ils ne sont pas documentés qu'ils sont inutiles.

1) Une instruction qui sert en interne chez Intel, par exemple lorsqu'ils testent les CPU en sortie de chaîne de fabrication. Typiquement, je pense que c'était le cas de , qui permet de récupérer des informations sur l'état interne du CPU, dont un programme "normal" n'est pas censé avoir besoin.

Impossible puisque ces instructions varient d'un CPU à l'autre. LOADALL est un cas très particulier.

Et alors ? Le fait qu'elles varient d'un CPU à l'autre empêche de les utiliser en bout de chaîne de fabrication ? À priori, quand un fabricant teste un CPU en bout de chaîne, il sait précisément quel type de CPU c'est, hein... Je pense pas qu'il ait besoin de tester au préalable le CPU pour savoir de quel type il est

De toute façon, les tests ne sont pas non plus les mêmes d'un modèle à l'autre, donc il faut connaître le modèle pour savoir quoi tester. Et donc il est possible de travailler à des instructions spécifiques à un modèle.

[zero]

Attention SartMatt, à vouloir avoir toujours le dernier mot, tu fini par contre-dire ce que tu écris juste avant (à iAPX).
Et explique en quoi l'utilisation de commandes non documentées. servirait de dianostique. (Explique nous en tenant compte de toutes les générations et des autres marques, pas seulement avec 2 ou 3 instructions particulières d'un Intel)

Edit: Ajout du "pas" manquant.

Ce message a été modifié par zero - 16 Aug 2018, 15:04.

[SartMatt]

Attention SartMatt, à vouloir avoir toujours le dernier mot, tu fini par contre-dire ce que tu écris juste avant (à iAPX).

En quoi je me contredis ? La discussion avec iAPX portait sur le fait que la compatibilité était assurée sur les instructions documentées dans le guide du developper IA-32 (puis Intel 64 & IA-32 depuis le passage au 64 bits).

Le fait qu'il y ait des instructions non documentées à usage interne ne remet pas en question ce fait.

Et explique en quoi l'utilisation de commandes non documentées. servirait de dianostique. (Explique nous en tenant compte de toutes les générations et des autres marques, seulement avec 2 ou 3 instructions particulières d'un Intel)

Un processeur, c'est un circuit extrêmement complexe. Le développeur "normal", il n'a pas accès à tous les états internes du CPU. Il n'a accès qu'à quelques registres.

Des instructions non documentées peuvent permettre de donner accès à ces états internes pour vérifier qu'ils sont conformes.

LOADALL en est un exemple connu, pour je ne sais quelle raison. Il y a sans doute des choses équivalentes sur pas mal d'autres CPU. Mais de par leur caractère non documenté, leur existence et leur syntaxe n'est pas nécessairement connue. Parce que s'il n'y a pas une fuite, c'est quand même compliqué de détecter une instructions non documentée sur un CPU, ça voudrait dire tester tous les opcode possibles, sachant qu'en x86, un opcode peut faire jusqu'à 15 octets, soit plus de 10^36 opcodes possibles. Et une fois l'instruction connue, encore faut-il trouver ce qu'il faut lui donner en paramètre et ce que signifie la réponse... Regarde une instruction comme CPUID, regarde les paramètres qu'elle prend en entrée, regarde les infos qu'elle donne en sortie : ce serait juste impossible de deviner tout ça si l'instruction n'était pas documentée. Donc il est tout a fait possible, et même très probable, qu'à peu près tous les CPU d'aujourd'hui aient des instructions non connues, pour donner accès à des informations internes (bon cela dit, sur un CPU à microcode upgradable, elles peuvent être retirées du microcode, donc au final être absente du CPU chez le client).

C'est exactement comme les connecteurs de diagnostic sur les appareils électroniques. C'est là pour donner accès à des informations internes auxquelles l'utilisateur normal n'est pas censé accéder, mais qui sont utiles pour vérifier le bon fonctionnement du produit et diagnostiquer un défaut.