Intel: x86-Lizenzvergabe an die Konkurrenz?
Wie die New York Times in ihrer Online-Ausgabe berichtet, hat die FTC im Zuge ihrer Monopolmissbrauchs-Klage gegen Intel eine Wunschliste mit Lösungsvorschlägen vorgestellt. Zwei davon haben es in sich und könnten den Markt umkrempeln.
Für den Fall, dass die FTC (Federal Trade Commision, Bundeshandelskommission der USA) das Gericht davon überzeugen kann, dass Intel sich im Sinne der Anklage rechtswidrig Verhalten habe, hat sie ein paar Lösungsvorschläge erarbeitet. Zwei davon sind besonders brisant und könnten sogar einen "Great Chip War" auslösen, glaubt die Autorin Ashlee Vance.
Zum einen ist das "relief measure No. 17":
Requiring Intel to make available technology (including whatever is necessary to interoperate with Intel’s CPUs or chipsets) to others, via licensing or other means, upon such terms and conditions as the Commission may order, including but not limited to extensions of terms of current licenses.
Vance versteht das so, dass Intel anderen Firmen eine x86-Lizenz* zur Verfügung stellen müsste - zum Beispiel Nvidia. Bislang besitzt Nvidia nämlich eben keine x86 Lizenz, und aufgrund von Streitigkeiten hat man auch die Entwicklung der passenden Chipsätze vorerst auf Eis gelegt. Andererseits halten sich hartnäckig Gerüchte, dass Nvidia trotz aller Dementi sozusagen im Geheimlabor an einem x86-kompatiblen Prozessor arbeitet. So verweist Vance darauf, dass Nvidia 70 Mitarbeiter des Prozessorherstellers Transmeta nach dessen Abwicklung übernommen hat - und Vance hegt keine Zweifel, woran diese bei Nvidia arbeiten.
Interessant ist auch "relief measure No. 18":
Prohibiting Intel from including or enforcing terms in its x86 licensing agreements that restrict the ability of licensees to change ownership, to obtain investments or financing, to outsource production of x86 microprocessors, or to otherwise partner with third parties to expand output.
Ganz klar würde hier geregelt, dass Intel einem Lizenznehmer nicht vorschreiben dürfe, woher er sein Kapital beziehe (also welche Investoren er an Bord holt) oder wer für ihn die Prozessoren herstelle. Selbst wenn der Lizenznehmer von einer Drittfirma gekauft würde, bliebe die Lizenz davon unberührt und würde weiter gelten - dann eben auch für die Mutterfirma.
Ob alles so kommt wie es Vance vermutet, steht natürlich noch in den Sternen. Noch hat der Prozess nicht wirklich begonnen, und es ist gut möglich, dass auch dieser mit einem Vergleich und nicht mit einer Verurteilung endet. Dennoch kann man natürlich spekulieren/hoffen/träumen was wäre, wenn Nvidia in Zukunft auch im x86-Markt als Prozessorhersteller mitmischen würde.
*(Möglicherweise ist das von der Autorin ein wenig frei interpretiert, denn aus der Formulierung geht nicht unbedingt hervor, ob es dabei nur um Lizenzen für Chipsätze oder eben auch für die Entwicklung von CPUs gehen soll.)
- Weihnachtsaktion: 60% Nachlass bei Ashampoo
- Lichtspektakel: Aplus Twin Engine II Color
- DRM-Desaster vermasselt Avatar-Vorpremiere
- Schnäppchencheck: Alienware Area 51
- Streaming-Schachtel: MSI Movie Station HD1000
- Speicher satt: 24 GB Triple-Channel von Corsair
- Apps fürs Auto? Bei Ford bald Wirklichkeit
- Fingern: LoiLoTouch-Videoschnitt am Touchscreen
- Kleiner Alleskönner: PlayOn!HD von AC Ryan
- MSI Wind U135 - Netbook mit Pine Trail
- Sky: Geldspritze und mehr HD-Kanäle
- Kochen wie Jamie Oliver - mit dem iPhone
- Gaming-Charts mit 108 Grafikkarten im Vergleich
- Geheimniskrämerei bei Coolermaster
- Cowon V5 HD: Player für unterwegs
- Hades: Gaming-Gehäuse von NZXT
- US-Gericht untersagt Microsoft Verkauf von Word
- Garantieverlängerung für Enermax Revolution85+





Also ich fänds klasse, wenn NVIDIA auch Prozessoren herstellen würde.
Die GPU's sind spitze, die Chipsätze waren klasse, die würden bestimmt auch gute CPU's hinbekommen.
Aber Intel und eine Verurteilung? Klingt unwarscheinlich.
Ich vermute mal, dass es auf ein cash settlement herauslaufen wird und Intel nicht alle Details zu x86 herausrückt, sodass lediglich x86-compatible Produkte von Konkurrenten hergestellt werden können.
Das Spielchen hatte AMD auch durchmachen müssen (siehe deren Pentium-ähnlichen K5 CPUs, die mit 133 MHz getaktet waren und im Pentium-Rating lediglich an einen P75 herankamen...)
Es würde mich wundern, wenn sich Intel DERART in die Suppe spucken lassen würde (zumindest freiwillig und ohne Gegenmassnahmen!)
Die beiden relief measurements sagen noch lange nicht aus, dass die Produkte von den Konkurrenten gleichwertig sein können. Sie müssen lediglich eine Kompatibilität zu Intel-Prozessoren herstellen können und der Konkurrent muss darüberhinaus auch die Befugnis haben, seine Produkte Ohne Abhängigkeit von Intel eigenständig zu veröffentlichen und die Kosten durch Forschung und Produktion hereinholen können.
Mit anderen Worten: Intel muss einen Teil seiner x86-Pläne frei verfügbar machen und Lizenzzahlungen good bye sagen!
Ersteres werden sie wohl machen (aber eben nicht alles), bei zweiterem werden sie warscheinlich Rekurs einlegen...
Man darf gespannt sein, wie der Krieg weitergeht!
... Mit anderen Worten: Intel muss einen Teil seiner x86-Pläne frei verfügbar machen und Lizenzzahlungen good bye sagen!
Dass es keine Lizenzzahlungen gäbe, halte ich für unwahrscheinlich, und das ist glaube ich auch nicht Absicht der relief measures. Vielmehr steht ja dort, dass (im Zweifelsfall unter Vermittlung durch die FTC) eine Lizenznehmervertrag erarbeitet werden soll. Ich glaube kaum, dass eine amerikanische Firma gezwungen wird, ihr Kerngeschäft ohne finanzielle und rechtliche Absicherung komplett offen zu legen.
DAs ist doch alles Albern ... Intel hat das nunmal entwickelt also sollen sie auch bestimmen können wer damit was macht .. wenn das den anderen nicht passt müssen sie halt was eigenes entwickeln ... aber da ist es einfacher mit klagen um sich zuwerfen ...
DAs ist doch alles Albern ... Intel hat das nunmal entwickelt also sollen sie auch bestimmen können wer damit was macht .. wenn das den anderen nicht passt müssen sie halt was eigenes entwickeln ... aber da ist es einfacher mit klagen um sich zuwerfen ...
Erst mal: Die Klage kommt von der Handelskommission, nicht AMD oder Nvidia.
Zweitens: Die Lizenz wäre auch kaum mehr als die Erlaubnis, überhaupt x86-CPUs entwickeln zu dürfen sowie eine "Übersicht" der Funktionen und Eigenheiten des x86-Befehlssatzes - und kein fertiger Bauplan. Aber eben diese Lizenzen vergibt Intel praktisch nicht, und darum geht es (nach Ansicht von Vance): den Markt zu öffnen.
@Chikko
Es geht dabei auch hauptsächlich um so Späßchen, dass Intel z.B. die ATOM-CPUs im Bundle mit dem eigenen Chipsatz günstiger verkauft als ohne! Damit wird natürlich die unbeliebte ION Konkurrenz künstlich verteuert und das ist sicher nicht i.O. (Die rede war dort von 25.- im Bundle gegen 45.- für die CPU alleine!)
Oh my - die 64-Bit-Erweiterungen (x86-64) stammen von AMD und werden von anderen (unter anderem auch Intel) nur lizenziert.
@suithmm... wie du vielleicht feststellen wirst sind die amd erweiterungen keine echten 64bit prozessoren sondern nur 32bit kerne die 64bit adressieren können!!! sonst könnte das teil nämlich nicht mit 32 bit laufen!!!
Autsch?
Ich glaube, du bringst entweder was durcheinander oder hast da was falsch verstanden. AMDs 64-Bit Erweiterungen sind sehr wohl voll 64-bittig. Schau dir dazu bitte einfach diese Seite unseres damaligen Testberichts an: 64 Bit fürs Volk: Athlon 64 FX, Athlon 64 vs. P4 Extreme
@suitnein da hast du etwas falsch verstanden... aber wenn du willst kannst du gerne probieren ein 16 bit betriebssystem auf nem 32bit prozessor zu instalieren oder umgekehrt!!! amd64 erlaubt nur das 64bit breite befehle bis zum prozessorkern vordringen können der prozessor selbst rechnet weiterhin mit 32 bit!!!
Ich vermute mal, du wolltest mir antworten und nicht suit.
Also denn: man kann natürlich immer noch 16-Bit Programme auf einem 32-Bit (x86-)Prozessor laufen lassen. Das geht auch auf den aktuellen 64-Bit-fähigen CPUs. Warum sollte das auch nicht gehen - alle Hersteller achten bei der Einführung neuer Erweiterungsbefehle (SIMD, SSE, 3DNow!) oder Fähigkeiten (x64) darauf, dass die CPUs abwärtskompatibel sind. Sonst würde man sich ja die Kundschaft vergrätzen, da man nie von heute auf morgen einen 100-prozentigen Systemwechsel vollzieht.
Zur Erinnerung: Windows 95/98/ME war ein buntes Gemisch aus 16- und 32-Bit-Elementen (aufbauend auf einem DOS!). Und das läuft, sofern man passende Treiber findet, auch auf heutigen Prozessoren. Erst Windows 2000 und danach XP waren voll 32-bittig.
Zum Athlon 64 - er kennt mehrere Betriebsmodi: reinen 32-Bit Betrieb, reinen 64-Bit Betrieb und den Legacy-Modus, in dem 32-Bit Anwendungen innerhalb eines 64-Betriebssystems (egal ob Linux oder Windows oder sonstwas) ausgeführt werden.
Im reinen 64-Bit Modus arbeitet er - der Name lässt es vermuten - entsprechend ausschließlich mit 64-Bit Code. Dabei stehen ihm sogar zusätzliche Rechen-Register zur Verfügung, was bei cleverer Programmierung auch zu einem Geschwindigkeitsvorteil führen kann.
Kannst du dein Argument
Wir sprechen hier von zwei Dingen - ich vom reinen ("native") 64-Bit Modus, du eben von 32-Bit Programmen in einer 64-Bit Umgebung (dem legacy mode). Und ich bin nach wie vor der Meinung, dass du dabei etwas falsch verstehst. Vorschlag: Wir recherchieren beide noch mal, und dann posten wir hier weiterführende Links, okay?

Eine Bitte: Weniger Ausrufezeichen tun es auch.
man kann auch auf windows 95 und 98 keine 16bit programme ausführen weil die die nicht emulieren kann... das kann erst windows 2000 und das unglaublich schlecht!!!
Warum genau soll man unter Win 95/98 keine 16-Bit Software ausführen können? Wenn das so stimmte, hätte man keine alten Spiele laufen lassen können - das war aber nicht der Fall. Ob ich beispielsweise Wing Commander im "echten DOS" oder unter Win95 Starte, ist dem Programm herzlich egal. Dass Win2000 nur bescheiden emulieren kann stimmt allerdings, liegt aber an der zugrundeliegenden Architektur, die bestimmte Zugriffe nicht erlaubt.
Leider sagt mir der Wikipedia-Artikel auch nicht mehr darüber, warum der Prozessorkern selbst im 64-Bit-Modus nur mit 32-Bit rechnen soll. Vielmehr sehe ich da meine Aussagen -auch zur Abwärtskompatibilität (16 & 32-Bit) bestätigt:
(...)
Alle Register haben bei AMD64 eine Breite von 64 Bit. Wenn der Prozessor im 32-Bit-Kompatibilitätsmodus läuft, werden die obersten 32 Bit jedes Registers auf 0 gesetzt. Im 64-Bit-Modus verfügt der Prozessor außerdem über je acht zusätzliche Integer- und SSE-Register, die im 32-Bit-Modus aus Kompatibilitätsgründen nicht verfügbar sind.
(...)
Es lassen sich zwei grundsätzliche Betriebsmodi unterscheiden:
* Legacy Mode: Hierunter fallen alle „alten“ Betriebsmodi der x86-Architektur, also Real Mode, Protected Mode und System Management Mode.
* Long Mode: Dieser Betriebsmodus besteht aus zwei Submodi:
o 64-Bit Mode: Der „echte“ 64 Bit Mode für 64-bittige Anwendungen auf einem 64-Bit-Betriebssystem.
o Compatibility Mode: Dieser Mode dient dazu, 32-bittige Anwendungen auch auf einem 64-Bit-Betriebssystem ausführen zu können. Die Anwendung „sieht“ dabei eine Umgebung, die dem Protected Mode zu entsprechen scheint. In Wahrheit werden aber dennoch Mechanismen der AMD64-Architektur benutzt, wie etwa eine vierstufige Seitentabellen-Hierarchie. Ebenso werden 16-Bit-Protected-Mode-Programme im Compatibility Mode unterstützt, nicht jedoch Real-Mode-Programme. Der Compatibility Mode muss explizit vom Betriebssystem für ein einzelnes Codesegment aktiviert werden.
Ich finde auch keinen Hinweis auf die von dir angeführte "Umrechnungslogik". Das Auffüllen mit Nullen passiert (wie ich sagte) nur im 32-Bit-Kompatibilitätsmodus, aber dabei werden nicht die "rechten" Nullen aufgefüllt (also die Stellen für 1,2,4,8,16,...) sondern wie der Artikel anmerkt die "linken", also obersten Nullen. Die Zahl bleibt also im Gegensatz zu deiner Aussage die gleiche.