Reprise du message précédent :

D'où l'intérêt d'un transcodeur qui prend un binaire x86 (32 ou 64 bit) et qui génère un binaire ARM.  
 

Le x86 ne tient que par la présence du BIOS sur les cartes mère. Côté ARM, c'est plus désordre qu'autre chose. D'ailleurs, c'est ce "désordre" qui fait qu'on ne peut pas changer facilement d'OS sur les smartphones.
Une fois qu'on aura la souplesse d'assemblage en ARM qu'on a aujourd'hui sur le x86, à ce moment là, les jours du x86 seront comptés. Quoi de mieux que d'avoir une appli qui s'installe pareil (comprendre le même fichier d'installation) sur le smartphone, la tablette et le desktop ?

 
Merci captain obvious    
 
La transition ne peut pas se faire comme ça d'un coup... c'est d'une évidence...
 
C'est bien pour ça qu'ils tentent une émulation du x86 pour effectuer une transition en douceur, car c'est sûr que c'est pas en lançant 2 devices avec un Windows RT et 0 apps dispo, store uniquement, ça va pas aider à la démocratisation...

 
 
Transmeta à fait de l'émulation X86 avec le Crusoé, c'est du reverse engineering  qui traduit les instruction X86 en instruction VLIW, d’ailleurs à cause ça il fallait mettre souvent à jour le BIOS de la carte mère afin de mettre à jour le micro-code du CPU.
 
VIA à une LICENCE X86 et peut être même X86-64 bit.
 
AMD fait de l'X86 et de AMD64.

 
Relis avec le doigt, il parle d'AMD64 et x86, pas d'arm  

Oh et donc tu vas bientôt nous sortir qu'il faut une licence x86 pour générer du code ARM qui tourne sur un CPU ARM?  

Vous ne vous êtes juste pas entendu sur la notion de "natif" depuis le début. L'un parlait natif x86, l'autre ARM.  
 
Forcément ça fait un beau dialogue de sourds à la fin.

Tu ne réponds toujours pas à la question.  
Plateforme ARM, on dépose des fichiers binaires x86, on transcode les binaires x86 en binaires ARM, et enfin on lance le binaire ARM généré.  
Dis moi où se trouve le point sur lequel Intel peut s'appuyer pour gueuler ?

Ça dépend la définition que tu donne a x86.

C'est une question délicate. J'aurais tendance à penser pareil, qu'en transcodant "offline" Intel n'a rien à dire car il s'agit à mon sens d'une recompilation.
 
Intel semble indisposé lors d'une émulation live : un émulateur x86 traite les instructions x86 et peut donc être vu comme un processeur, software certes, mais processeur. Ce point de vue semble s'imposer pour QEMU, qui ne propose pas d'émuler x86 sur autre chose que x86. Peut-être sinon est-ce par manque de demande, mais venant d'un projet open-source pareil, je n'y crois pas trop.
 
Dans le cas de l'émulateur de Microsoft, je pense que les CHPE DLLs ne posent pas de problème, par contre on ne peut en dire autant de l'émulateur sous WoW. Il fonctionne selon le même principe que Denver, et nVidia avait eu des problèmes de licence...

Pas oublier que c'est avant tout un coup de comm' d'Intel qui veut tenter de couper l'herbe sous le pied de l'idée même d'un W10 arm.
 
Le coup de comm' peut même se transformer en coup de force sans qu'il n'y ait de fond de validité juridique derrière les arguments. Ca peut être suffisant pour intimider ou retarder un lancement.  
 
(et sinon sur le fond de la question de l'émulation on en avait déjà parlé, et le fait qu'Intel ait toléré/participé à QEMU affaiblira fortement une position déjà faible légalement, l'émulation n'ayant jamais vraiment été "testée" légalement, mais le peut qui s'est fait [l'affaire Bleem!] va plutôt dans le sens de MS qui a probablement mis un avocat et demi sur le sujet avant de se lancer)

 
Le flop de RT vient plus de la limitation au apps du store que de l'arm.

 
Cela fait penser que dans le passé il y avait au moins 4 fabricant de processeur X86... Il y a avait bien sur Intel, AMD, et aussi Cyrix (Maintenant Via) et Je crois aussi Winbond si je me trompe pas mais le 4ème ma mémoire est pas parfait ça demanderais vérification alors dans le passé la compétition des processeurs X86 était plus élevé...

Il y avait aussi nexgen, idt ou rise, y'en a eu des fabriquants de x86.
Au passage nexgen ont été à AMD ce que ArtX ont été à ATi...
 

Sans compter IBM et NEC, qui avaient de meilleurs perfs, on ne parle pas des FPU

Effectivement, je vois rien qui permette d'épingler le combo désassemblage/retranscription, on ne peut même pas parler de reverse engineering, puisque l'app est conservée sans modification fonctionnelle.
 
Après, faut quand même une sacrée usine à gaz pour "recompiler" une app de la sorte (le parser doit connaître toutes les syntaxes asm) et se pose encore le problème de la modularité des programmes sous Windows : quid des DLL en pagaille, qui sont elles-mêmes constituées en grande partie de code machine et dont la fonctionnalité est liée à des points d'entrée qui ne pourraient pas être conservés? Là encore il faut un parser bourrin retranscrivant toute la structure d'une DLL, qui contient normalement les points d'accès, bien qu'il me semble que ça ne soit pas une obligation pour des raisons de sécurité...

 
Ca s'appelle de l'émulation JIT. Je vois même pas comment on envisagerait de faire de l'émulation autrement si on veut que ce soit efficace.
Le Dec Alpha tournaient avec un tel compilateur x86->Dec Alpha (CPU Risc). Les exécutables ainsi générés au premier lancement étaient stockés en cache. Ces exécutables x86 étaient parfois plus rapides sur Dec Alpha (un CPU Risc sensiblement plus rapide que ceux d'Intel) que sur le haut de gamme Intel.
 
Alors Intel a racheté les technos CPU de DEC (et les usines et leur techno de gravure plus avancée que chez Intel), même si Compaq avait racheté l'entreprise DEC. Certains acteurs ont acquis une licence d'exploitation de l'architecture DEC Alpha (à l'image de ce qui se fait pour ARM), notamment Samsung. Donc grosse chance que cette techno et des brevets afférents soient aux mains d'Intel. Sinon ça serait HP, probablement HPE qui l'aurait. Répliquer le même concept pourrait tomber sous le coup d'une violation de brevet.
 
Il existe actuellement plusieurs émulateurs hardware PC x86/PC assez complet (donc comprenant des instructions X64).
Bochs, assez ancien déjà (une 20aine d'années). Il est sous LGPL. Supporte tous les CPU du marché.
Il y a aussi QEMU, un Bochs amélioré, plus rapide (proche du JIT).
Intel peut ne pas avoir été regardant, mais il est fort à parier qu'il ne peut rien faire de concret contre.
 
Par contre Intel laisse entendre que si Qualcomm a utilisé du code X86 dans leur ARM 835, soit du microcode, même reprogrammable, faisant appel niveau hardware au sous-ensemble ARM pour émuler de façon hardware du x86/64, ce CPU ARM étendu pourrait être considéré lui-même comme un CPU x86/64. Donc en gros, le CPU x86 serait émulé au sein du 835 même. C'est ce que faisait à ma connaissance Transmeta, qui était bien en procès contre Intel.

On sait que ce n'est pas le cas vu que c'est un Cortex A73 rebadgé, le Qualcomm Intel a juste voulu faire un coup de comm/force cf commentaire précédent.

D'ailleurs, quelqu'un pourrait confirmer mon souvenir relatif à NT permettant une "concaténation" des binaires de différentes ISA?
 
A l'époque je me souviens très bien que NT supportait les plateformes ARM, SPARC et peut-être même encore une autre archi (Alpha?), puisque lors de l'installation il fallait choisir (pas très "plug & play" tout ça ).

Ouais enfin sinon y'a pas besoin de licence pour faire de l'émulation. En logiciel il n'y'a pas de brevet : si tu veux coder un émulateur en rétro engineering tu peux le faire et c'est parfaitement légal. Ce qui est interdit c'est d'utiliser du code sous licence (ex une DLL), ou de copier directment le code source. Tous les exemples de licence x86 ou ARM, sont des constructeurs de CPU, là pour fondre un CPU le brevet s'applique.
 

Bonjour
Intel n'aime pas vendre un processeur performant et pas cher
https://www.techpowerup.com/235035/ [...] y-kills-it

Ça s'appelle une boucle, la source de cet article est DigiWorthy qui a pour source ... HardWare.fr, avec une belle déformation au passage.

Il ne te reste plus qu'a faire une news avec eux en source et la boucle est bouclée !  

Pénurie a cause des mineurs qui on besoin d'un cpu pas chere et qui consomme peu

Pour miner un Celeron suffit. Ou alors ils ont penser à la revente ?
Je pari plus sur un stock assez faible.

Finalement ça serait bien Intel qui aurait arrêté, du moins freiné la prod du G4560 qui effectivement cannibalisait la vente de i3.
https://www.techpowerup.com/235035/ [...] y-kills-it

Des CPU+GPU multicouches x86 128 cores/256 threads 7nm 32 couches, fonctionnant à 5Ghz et avec un GPU qui fait du calcul mathématique brut parallèle intégré au système. Bien sur entouré de stacks HBM. Je vois pas le problème. Les gens prévoyants auront changé 2 fois de config en 10 ans pour suivre. Avec un nouvel OS Windows encore plus fermé...  
Tout ça avant de passer au nanotubes.
 
On pourra faire tourner Half Life en mode VM x86 avec le nouveau patch edition 30 ans après (pour info Half Life vient de recevoir un nouveau patch 19 ans après sa sortie c'est bien pour le premier volet alors pourquoi pas un autre dans 10 ans   ).

Lire quelques message au-dessus...

 
   
 
Ce parachutage raté. De l'art !

C'est plus de la déformation là,

qui devient

Pour ceux qui cherchent, sur Amazon Allemagne, il est à 81€. Ca reste très bon. Sur Amazon Italie il est à 64€ mais envoi entre 1 et 2 mois ...