Processeur x86 et licences

[Dandu]

Je me pose une question bête :

il y a quelques années, il y avait pas mal de sociétés qui faisaient du x86. Actuellement, plus trop.

Je sais qu'il faut une licence pour faire des CPU compatibles x86, mais elle couvre quoi la licence ?

Parce que quand je lis chez Digitimes que nVidia pourrait racheter Via pour récuperer la licence x86 de ce dernier, alors que nVidia produit déjà des CPU x86 (cf. http://www.nvidia.com/page/uli_m6117c.html), je me dis que c'est un peu moins simple que de payer pour faire "du x86".

Ca dépend du jeu d'instruction ?

[Doc TB]

Ce n'est pas tant le jeu d'instruction x86 en lui meme dont il faut avoir la license pour produire un CPU commercialement viable, mais surtout avoir une license pour le bus d'interconnection. Parceque si tu n'utilises pas le bus QDR des CPU Intel, il te faut un chipset dédié et aucun fabricant ne va te faire un chipset pour ton CPU sans savoir à l'avance ce qu'il vaut. D'ou l'idée de racheter VIA qui dispose d'un departement chipsets ET de la licence du bus QDR Intel.

[Dandu]

Oui, mais pour nVidia, ils pourraient développer leur chipset eux-même, non ?

Mais est-ce que si on dispose de la licence pour un 386sx (comme ici), on a aussi la possibilité d'utiliser des jeux d'instructions plus récents ? Ou bien est-ce que ça se limite à certains trucs.

[Neo_13]

vu les délais, je dirais que c'est une histoire de brevets devenu caduque non ?

[Gabriel]

Au niveau des jeux d'instructions, je pense qu'il y a des protections partielles par brevets. On ne peut pas breveter un jeu d'instructions, mais dans le tas on en trouve bien quelques unes dont on peut protéger le principe par des brevets suffisament larges pour les protéger efficacement. (en tous cas, ça me parait faisable)

Le fait q'AMD ait tout d'abord introduit le "enhanced 3dnow!", qui reprenait certaines parties du SSE, sans utiliser le jeu d'instructions SSE complet, semble aller dans ce sens.

Il me semble également avoir lu à plusieurs reprises qu'Intel et AMD avaient actuellement des accords de cross-licensing, leur permettant d'implémenter SSEx et AMD64.

Donc je dirais non à la question: il est peu vraiscemblable qu'une license 386 permette d'implémenter en totalité les jeux SSEx.

(Par contre, avec une license 386 on peut faire du 486, comme l'on fait Cyrix et IBM)

[Doc TB]

(Par contre, avec une license 386 on peut faire du 486, comme l'on fait Cyrix et IBM)

Et se prendre un procés au cul et le perdre...

[Gabriel]

De mémoire, il me semble que Cyrix n'a pas perdu ce procès, qui n'est d'ailleurs jamais passé en jugement.

[ylyad]

Ce genre de choses se finit rarement au tribunal, mais de là à dire qu'ils n'ont pas perdu, c'est un raccourci un peu hâtif

[Gabriel]

Ben techniquement, sans jugement, on ne peut pas perdre de procès.
Ceci dit, on est tous d'accord (je pense) pour dire qu'il y a tout de même un certain rapport de force en faveur d'Intel, et qu'en faisant ce genre de choses on ne s'attire pas que des amis.

edit:
Bon, apparament Cyrix et IBM ne sont pas ressortis perdants:
http://findarticles.com/p/articles/m..._15071564/pg_1

[Doc TB]

Bon, apparament Cyrix et IBM ne sont pas ressortis perdants:
http://findarticles.com/p/articles/m..._15071564/pg_1

Ni gagnant ! Cyrix a bien eu le droit de produire des 486, mais UNIQUEMENT dans les usines qui disposaient déjà d'une license pour produire des CPU Intel-like. DAns le meme temps, AMD a perdu devant la court : http://query.nytimes.com/gst/fullpag...pagewanted=all
C'est d'ailleurs pour ça qu'il y a des AMD 486 d'avant et d'aprés ce jugement, les seconds sont plus lent

[Gabriel]

Uniquement dans les usines qui avaient déjà une license, mais ils ont aussi reçu 5 millions en échange de l'abandon de leur plainte anti-trust. Bon, avec le recul, c'était peut-être pas une bonne idée d'accepter ce marché.

Interessant le lien sur AMD. J'ignorais qu'ils avaient directement utilisé le micro-code d'Intel. C'était effectivement plus que limite de la part d'AMD comme pratique.

Note: aucun des 2 cas ne concerne le jeu d'instructions à proprement parlé.

[Childerik]

J'ignorais qu'ils avaient directement utilisé le micro-code d'Intel. C'était effectivement plus que limite de la part d'AMD comme pratique.

Ca a souvent été le cas chez amédé : Steeve Jobs parle de MS comme étant une photocopieuse de service de OSX. C'est un peu la même chose avec amédé vis-à-vis d'Intel (numérotation des phenoms, AVT (le nom, pas la technologie), cache L3, Live (vs Vaïve) etc ...)

[Foudge]

Pas convaincu par tous les exemple donnés entre parenthèses
Surtout que les contre exemple existent aussi...

[Eld]

sauf erreur, c'est AMD qui a commencé à faire du x86 en RISC (en interne), et Intel qui a suivi

[Neo_13]

c'est intel qui a créé le premier microprocesseur à transistors ; tous les autres ont suivi.

Voilà, débat clos.

[Childerik]

Pas convaincu par tous les exemple donnés entre parenthèses
Surtout que les contre exemple existent aussi...

sauf erreur, c'est AMD qui a commencé à faire du x86 en RISC (en interne), et Intel qui a suivi

c'est intel qui a créé le premier microprocesseur à transistors ; tous les autres ont suivi.

Voilà, débat clos.

Voilà (j'hésite à citer le 790FX, nom étrangement ressemblant à quelque chose qui gère du SLi ).

[fefe]

sauf erreur, c'est AMD qui a commencé à faire du x86 en RISC (en interne), et Intel qui a suivi

Oui mais ca a quel rapport avec la discussion ? C'est aussi AMD le premier a avoir fait des x86-64 bits, etc...
Intel et AMD ont un accord de cross licencing complet aujourd'hui, donc qui a fait quoi en premier importe relativement peu.

[Eld]

Oui mais ca a quel rapport avec la discussion ? C'est aussi AMD le premier a avoir fait des x86-64 bits, etc...
Intel et AMD ont un accord de cross licencing complet aujourd'hui, donc qui a fait quoi en premier importe relativement peu.

c'était un exemple pour aller avec "Surtout que les contre exemple existent aussi...", rien de plus
et x86-64, c'est mal, j'ai au moins pris le soin de citer un exemple favorable à amd ^^

[Lissyx]

En quoi x86-64 c'est mal ?

[Neo_13]

En quoi x86-64 c'est mal ?

On peut toujours acceder au x87 en mode 64bits...

[Eld]

c'est mal parce que c'est dommage de ne pas avoir profité du passage à 64 bits pour enfin changer réellement d'assembleur (ce qu'Intel voulait faire avec IA64)
malheureusement la rétrocompatibilité a encore frappé et gagné :/

[Lissyx]

c'est mal parce que c'est dommage de ne pas avoir profité du passage à 64 bits pour enfin changer réellement d'assembleur (ce qu'Intel voulait faire avec IA64)
malheureusement la rétrocompatibilité a encore frappé et gagné :/

Certes, mais ils l'auraient fait, leurs CPUs ils se les gardaient sur les bras je pense.

[Eld]

ouai mais c'est un peu déprimant cette histoire, il y a ENFIN un changement qui va obliger les vendeurs de soft à fournir d'autres binaires, et non, raté, on reste dans la continuité...

[Neo_13]

Certes, mais ils l'auraient fait, leurs CPUs ils se les gardaient sur les bras je pense.

alors qu'en gardant la compatibilité complète en 32 bits et en sucrant le x87 en 64bits, ils se débarrassaient d'une première tare du x86.

[fefe]

alors qu'en gardant la compatibilité complète en 32 bits et en sucrant le x87 en 64bits, ils se débarrassaient d'une première tare du x86.

Il y a des gens qui ne veulent pas voir disparaitre la FPU en 80bits... Et pour qui accelerer une appli vieille de 20 ans en changeant juste de machine est la seule chose qui compte...

[Møgluglu]

alors qu'en gardant la compatibilité complète en 32 bits et en sucrant le x87 en 64bits, ils se débarrassaient d'une première tare du x86.

Dans la mesure où les compilos génèrent par défaut du SSE2 au lieu du X87 en mode 64 bits (du moins ceux que je connais), ça ne change pas grand-chose.

Vu qu'il faillaient qu'il en payent de toute façon le prix en matériel, ils n'avaient pas de raison particulière d'interdire le X87 (et la double-étendue) en mode 64 bits.
Et j'imagine mal un proco x86-64 uniquement non compatible IA32, même dans 5 ou 10 ans.

Le x86-64 a toujours l'avantage d'englober toutes les évolutions de l'ISA entre le 386 et le K8/P4, donc les compilos peuvent enfin balancer des CMOV et du SSE par défaut.

[ylyad]

Il y a des gens qui ne veulent pas voir disparaitre la FPU en 80bits... Et pour qui accelerer une appli vieille de 20 ans en changeant juste de machine est la seule chose qui compte...

Tu a des exemples? (sincèrement intéressé)

[Yasko]

Tu a des exemples? (sincèrement intéressé)

C'est pour de la prospection ?

Ouais, dtfacon, les applis vieilles de 20 ans qui tournent encore de nos jours, elles sont sur mainframe.

[ylyad]

Je ne demande pas de nom juste des exemples d'applications. Je veux dire, les specs sont surprenantes de premier abord: qui tournent sur x86, ont une quinzaine d'années environ (si x87 et pas SSEx), donc sur PC, en assembleur (?), suffisamment stables pour qu'on ne souhaite pas les upgrader MAIS pouvant voire nécessitant de voir leur temps d'exécution accéléré (donc pas forcément de l'info indus où on peut aller jusqu'à chercher à conserver un temps d'exécution constant), dont on n'a pas le source/les compétences pour les recoder, etc. Bon, j'extrapole (un peu...), mais c'est curieux, ou plutôt, ça excite ma curiosité .

[fefe]

Tu parts du principe que tout le monde a encore les sources/version recompilable d'une appli (ou un developpeur capable de toucher a un environement de dev super obsolete avec du code non comente)... Et c'est la que tu te trompes .