Diskussion:X86-Prozessor

Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „X86-Prozessor“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen.

• Diskussionsregeln
• Hilfe zu Diskussionsseiten
• Sei sachlich und freundlich!
• Greife niemanden persönlich an!
• Geh von guten Absichten aus.

Archiv

2003 2005 2006 2007 2009 2017

Wie wird ein Archiv angelegt?

Automatische Archivierung

Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind. Die Archivübersicht befindet sich unter Archivübersicht.

Vorlage:Autoarchiv-Erledigt/Wartung/Festes_Ziel

MMX

Was ist 'MMX-Intriniscs'? Kann ich nicht finden, was das sein soll! (nicht signierter Beitrag von P3t3rpoe (Diskussion | Beiträge) 13:59 04. Sep 2008 (CEST))

Intrinsics sehen im Quellcode aus wie eine Funktion, tun aber nichts weiter als den Compiler anzuweisen, an dieser Stelle eine entsprechende MMX-Instruktion einzusetzen. Intrinsics-Programmierung ist ziemlich low-level, denn der Programmierer muss MMX (oder SSE oder was auch immer) verstanden haben und wissen was er will. Die Alternative ist, dem Compiler beizubringen, selbstständig solche Instruktionen zu generieren, wenn er das für sinnvoll hält. --Echoray 14:40, 4. Sep. 2008 (CEST)

Virtualisierung

Weiss jemand, was genau Popek und Goldberg gesagt haben? ... oder auch nur ungefähr? Wo liegen die Probleme in der Virtualisierung? -cljk 23:09, 2. Mär 2005 (CET)

Vielleich hilft Dir das weier: http://en.wikipedia.org/wiki/Popek_and_Goldberg_virtualization_requirements und http://www.kernelthread.com/publications/virtualization/ --Djj 23:53, 2. Mär 2005 (CET)

Wie wäre es den Abschnitt mal zu überarbeiten. Mitlerweile können alle aktuellen CPUs von AMD und Intel "effizient virtualisieren" (boa klingt das geil :-D )

--K4m1K4tz3 15:37, 24. Mai 2007 (CET)

Textverständnis

Ich hab mal ein bisschen in diesem Artikel gelesen und folgenden Satz entdeckt:

"MMX definierte 8 neue SIMD-Register von 64 Bit Breite, die allerdings auf den Stack der FPU gemappt waren."

Das ist nicht allgemein verständlich. Kann bitte jemand dieses Fachchinesisch ins Deutsche übersetzen?

--Grode 10:30, 22. Okt. 2006 (CEST)

Die Ansprüche von Popek, Goldberg und Breen?

Hat eigtl irgendjemand eine Ahnung wer diese drei Herren sein sollen? Bzw was für Ansprüche sie gestellt haben... Eine Google-Suche hat mir dazu nichts verraten und Wikipedia kennt auch keinen Popek. Ohne wenigstens kurz zu umschreiben worum es sich dabei handelt ist diese Anmerkung doch ziemlich überflüssig... (nicht signierter Beitrag von 91.5.50.3 (Diskussion) 18:38 23. Okt 2007 (CEST))

Siehe Absatz "Virtualisierung" weiter oben.--Ruscsi 19:21, 23. Okt. 2007 (CEST)

Übersicht Anzahl Instruktionen

Hallo,

unter X86-Prozessor#Streaming_SIMD_Extensions hab ich eine Tabelle hinzugefügt, auf der die Anzahl der Instruktionen, die pro SSE-Erweiterung hinzugekommen sind, aufgeführt sind. Dadurch kriegt man ein Gefühl, in welchen Größenordnungen sich die Instruktionssätze befinden. Allerdings befürchte ich, dass ich mit dieser Tabelle in der Wikipedia nicht nur auf frohe Gesichter stoßen werde, denn die Zahlen und die Auswahl der Instruktionssätze sind nicht hieb- und stichfest. Um gleich die Killerargumente zu nennen:

• Ich hab nur die wichtigsten Instruktionssätze summiert, da 3DNow! etwa keine akzeptable Verbreitung genießt und damit die Summierung sinnentkräften würde
• Die Zahlen in der Spalte Anzahl Instruktionen entstammen im Wesentlichen den entsprechenden Wikipedia-Artikeln, aber auch etwa en:X86_instruction_listings, en:Instruction_set und den englischsprachigen Artikeln über die entsprechenden SSE-Erweiterungen. Das Problem ist aber vor allem, dass Intel etwa aus Marketingzwecken zu große Zahlen genannt hat. Daher hab ich jeweils die kleineren Zahlen ausgewählt, um der Realität näher zu kommen.

Über beide Punkt lässt sich streiten, und ich bin sicher, dass sich diskussionsfreudige Wikipedianer nicht darum reißen lassen werden, meinen Edit zu reverten. Nur her damit... ich hab sowieso keine Lust zu diskutieren, aber falls jemand anderes das vorhat, sei hiermit eine Möglichkeit gegeben :-) --Benji 00:12, 20. Mär. 2010 (CET)

Sind die Befehlssätze so aufeinander aufbauend? Die Summen passen jedenfalls nicht zu den Anzahlen in der mittleren Spalte. -- Paul E. 16:31, 24. Sep. 2010 (CEST)

9. Generation?

Jetzt mal abgesehen davon, was die Marketing-Leute von Intel behaupten: mMn ist der Unterschied zwischen der Architektur der Intel-Core-2-Serie und der Intel-Core-i-Serie nicht so groß, dass man die Core--Serie als neue Generation betrachten kann. Immerhin werden Pentium Pro, Pentium II und Pentium III ja auch üblicherweise alle zur selben generation gezählt. Bei der Core-i-Serie ist es war üblich geworden, eine GPU in der Die der CPU zu integrieren, aber eine GPU hat mMn nichts mit der CPU-Architektur zu tun, nicht mal wenn sie auf der selben Die ist wie die CPU. --MrBurns (Diskussion) 23:30, 29. Jun. 2013 (CEST)

Wie immer die Diskussion ausgehen mag, im Moment sind zwei einander widersprechende Tabellen im Artikel, das kann so nicht bleiben. --RokerHRO (Diskussion) 18:03, 20. Jan. 2014 (CET)

Die 2. Tabelle scheint mir überhaupt Blödsinn zu sein, da wurde ab der 10. Generation einfach jede neue Intel-Mikroarchitektur, außer Haswell und die, die nur Die-Shrinks sind (siehe en:Intel Tick-Tock), einer neuen Generation zugeordnet, diese Einteilung ist mir sonst noch nirgendwo untergekommen. --MrBurns (Diskussion) 02:54, 21. Jan. 2014 (CET)

Okay. Das spricht ja für: Weg damit! :-) --RokerHRO (Diskussion) 07:56, 23. Jan. 2014 (CET)

amd64

>Für 64-Bit-Prozessoren, die auf der x86-Architektur beruhen wird die Bezeichnung x86-64 oder kurz x64 verwendet.

Gerade unter unixoiden Betribssystemen wird weiterhin die Bezeichnung amd64 verwendet.(genauso wie i386,...,i686 für x86-32)--84.184.175.200 22:58, 31. Jul. 2014 (CEST)

Generationen durchgezählt

Die Tabelle mit den Generationen von x86-Prozessoren… ist die irgendwie belegt? Mir kommt es nämlich komisch vor, die hier durchzunummerieren. i386 soll demnach die 3. Generation gewesen sein? Und Athlon 64 die 8. Generation? Wo steht das? Wer sagt sowas? Ich denke da an WP:TF… ‣Andreas•⚖ 20:50 01. Jän 2015 (CET)

Bis zu 8. Generation ists eigentlich relativ unumstritten, danach gibts unterschiedliche Definitionen, daher halte ich diese Generationentabellen generell für fragwürdig. Siehe auch Abschnitt 9. Generation. --MrBurns (Diskussion) 08:59, 2. Jan. 2015 (CET)

x86-Architektur

Eigentlich sollte dieser Artikel in x86-Architektur umbenannt werden. Gibt es Einwände/Meinungen dazu? ‣Andreas•⚖ 11:57, 30. Apr. 2017 (CEST)

Nun haben wir 2021: sollten wir nicht doch den x86-Prozessor von der x86-Architektur trennen und zwei Artikel machen? Gibt es denn Meinungen dazu?

Ich schlage vor, den ersten Teil im Artikel zu belassen, das ist die Geschichte und die Nomenklatur, sowie die Übersicht der Generation und die Hersteller, jedoch den gesamten Abschnitt Design in einen neuen Artikel x86-Architektur zu verschieben.

‣Andreas•⚖ 13:10, 6. Nov. 2021 (CET)

Ich würde vorschlagen es bei einem Artikel zu belassen und den Artikel in x86-Architektur umzubenennen, denn das wäre in der Tat die bessere Bezeichnung für das, was hier beschrieben werden soll. x86-Prozessor kann dann auf x86-Architektur verweisen.

Der Grund warum ich einen extra Artikel Namens x86-Prozessor nicht gut finde liegt daran, weil es nicht "den" x86 Prozessor gibt.

Außerdem ist der Artikel noch bezüglich dem Design ausbaubar. Es fehlt bspw. eine visuelle übersichtliche Darstellung der ganzen Register. Das werde ich aber in einem extra Abschnitt hier erwähnen, da es ein anderes Thema ist.

Eränzung:

Bezüglich der Diskussion mit den Grafiken siehe Diskussion:X86-Prozessor#Grafik bezüglich Darstellung der Register fehlt.

Außerdem würde es meiner Meinung nach noch Sinn machen, wenn man in den Artikel x86-Architektur die Unteraabschnitte x86-16, x86-32 und x86-64 einführt und die Punkte dann entsprechend separat behandelt. Das würde es auch vereinfachen, die 3 Grafiken mit den Registern richtig einzugliedern. --IT-Compiler (Diskussion) 20:51, 6. Mär. 2022 (CET)

Show you a table to be evaluated...

The Chronology of x86 Processors

Generation		Introduction	Prominent CPU models	Address Space			Notable features
				Linear	Virtual	Physical
x86	1st	1978	Intel 8086, Intel 8088(1979)	16-bit	NA	20-bit	16-bit ISA, IBM PC (8088), IBM PC/XT (8088)
		1982	Intel 80186, Intel 80188 NEC V20/V30(1983)				8086-2 ISA, embedded (80186/80188)
	2nd		Intel 80286 and clones		30-bit	24-bit	protected mode, IBM PC XT 286, IBM PC AT
	3rd (IA-32)	1985	Intel 80386, AMD Am386 (1991)	32-bit	46-bit	32-bit	32-bit ISA, paging, IBM PS/2
	4th (pipelining, cache)	1989	Intel 80486 Cyrix Cx486S/DLC(1992) AMD Am486(1993)/Am5x86(1995)				pipelining, on-die x87 FPU (486DX), on-die cache
	5th (Superscalar)	1993	Intel Pentium, Pentium MMX(1996)				Superscalar, 64-bit databus, faster FPU, MMX (Pentium MMX), APIC, SMP
		1994	NexGen Nx586 AMD 5k86/K5 (1996)				Discrete microarchitecture (µ-op translation)
		1995	Cyrix Cx5x86 Cyrix 6x86/MX(1997)/MII(1998)				dynamic execution
	6th (PAE, µ-op translation)	1995	Intel Pentium Pro			36-bit (PAE)	µ-op translation, conditional move instructions, dynamic execution, speculative execution, 3-way x86 superscalar, superscalar FPU, PAE, on-chip L2 cache
		1997	Intel Pentium II, Pentium III (1999) Celeron(1998), Xeon(1998)				on-package (Pentium II) or on-die (Celeron) L2 Cache, SSE (Pentium III), SLOT 1, Socket 370 or SLOT 2 (Xeon)
		1997	AMD K6/K6-2(1998)/K6-III(1999)			32-bit	3DNow!, 3-level cache system (K6-III)
	Enhanced Platform	1999	AMD Athlon, Athlon XP/MP(2001) Duron(2000), Sempron(2004)			36-bit	MMX+, 3DNow!+, double-pumped bus, Slot A or Socket A
		2000	Transmeta Crusoe			32-bit	CMS powered x86 platform processor, VLIW-128 core, on-die memory controller, on-die PCI bridge logic
			Intel Pentium 4			36-bit	SSE2, HTT (Northwood), NetBurst, quad-pumped bus, Trace Cache, Socket 478
		2003	Intel Pentium M Intel Core (2006), Pentium Dual-Core (2007)				µ-op fusion, XD bit (Dothan)
			Transmeta Efficeon				CMS 6.0.4, VLIW-256, NX bit, HT
IA-64	64-bit Transition 1999 ~ 2005	2001	Intel Itanium (2001 ~ 2017)	52-bit			64-bit EPIC architecture, 128-bit VLIW instruction bundle, on-die hardware IA-32 H/W enabling x86 OSes & x86 applications (early generations), software IA-32 EL enabling x86 applications (Itanium 2), Itanium register files are remapped to x86 registers
x64	64-bit Extended since 2003	x64 is the 64-bit extended architecture of x86, its Legacy Mode preserves the entire and unaltered x86 architecture. The native architecture of x64 processors, residing in the 64-bit Mode, lacks of access mode in segmentation, presenting 64-bit architectural-permit linear address space, currently, only 48-bit of which is implemented; an adapted IA-32 architecture residing in the Compatiblity Mode alongside with 64-bit Mode is provided to support most x86 applications
		2003	Athlon 64/FX/X2(2005), Opteron Sempron(2004)/X2(2008) Turion 64(2005)/X2(2006)	40-bit			AMD64 (except some Sempron processors presented as purely x86 processors), on-die memory controller, HyperTransport, on-die dual-core (X2), AMD-V (Athlon 64 Orleans), Socket 754/939/940 or AM2
		2004	Pentium 4 (Prescott) Celeron D, Pentium D (2005)	36-bit			EM64T (enabled on selected models of Pentium 4 and Celeron D), SSE3, 2nd gen. NetBurst pipelining, dual-core (on-die: Pentium D 8xx, on-chip: Pentium D 9xx), Intel VT(Pentium 4 6x2), socket LGA 775
		2006	Intel Core 2 Pentium Dual-Core (2007) Celeron Dual-Core (2008)				Intel 64 (<<== EM64T), SSSE3(65nm), wide dynamic execution, µ-op fusion, macro-µ-op fusion, on-chip quad-core(Core 2 Quad), Smart Shared L2 Cache
		2007	AMD Phenom/II(2008) Athlon II(2009), Turion II(2009)	48-bit			Monolithic quad-core(X4)/triple-core(X3), SSE4a, Rapid Virtualization Indexing (RVI), HyperTransport 3, AM2+ or AM3
		2008	Intel Core 2 (45nm)	36-bit			SSE4.1
			Intel Atom				netbook or low power smart device processor, P54C core reused
			Intel Core i7 Core i5 (2009), Core i3 (2010)				QuickPath, on-chip GMCH (Clarkdale), SSE4.2, Extended Page Tables (EPT), LGA 1366 (Nehalem) or LGA 1156 socket
			VIA Nano				hardware-based encryption; adaptive power management
		2010	AMD FX	48-bit			octa-core, CMT(Clustered Multi-Thread), FMA, OpenCL, AM3+
		2011	AMD APU A and E Series (Llano)	40-bit			on-die GPGPU, PCI Express 2.0, Socket FM1
			AMD APU C, E and Z Series (Bobcat)	36-bit			low power smart device APU
			Intel Core i3, Core i5 and Core i7 (Sandy Bridge/Ivy Bridge)				Internal Ring connection, LGA 1155 socket.
		2012	AMD APU A Series (Bulldozer, Trinity and later)	48-bit			AVX, Bulldozer based APU, Socket FM2 or Socket FM2+
			Intel Xeon Phi (Knights Corner)	48-bit			coprocessor OS powered PCI-E Card Formed coprocessor for XEON based system, Many Core Chip, In-order P54C, very wide VPU (512-bit SSE), LRBni instructions (8× 64-bit)
		2013	AMD Jaguar (Athlon, Sempron)	48-bit			SoC, game console and low power smart device processor
			Intel Silvermont (Atom, Celeron, Pentium)	36-bit			SoC, low/ultra-low power smart device processor
			Intel Core i3, Core i5 and Core i7 (Haswell/Broadwell)	39-bit			AVX2, FMA3, TSX, BMI1, and BMI2 instructions, LGA 1150 socket
		2015	Intel Broadwell-U (Intel Core i3, Core i5, Core i7, Core M, Pentium, Celeron)				SoC, on-chip Broadwell-U PCH-LP (Multi-chip module)
		2015/2016	Intel Skylake/Kaby Lake/Cannonlake (Intel Core i3, Core i5, Core i7)	46-bit			AVX3
		2016	Intel Xeon Phi (Knights Landing)	48-bit			Bootable and standalone accelerator supplement to Xeon system, Airmont (Atom) core based
		2016	AMD Bristol Ridge (AMD (Pro) A6/A8/A10/A12)	48-bit			Integrated FCH on die, SoC, AM4 socket
		2017	AMD Ryzen Series/AMD Epyc Series				AMD's implementation of SMT, Socket with over too many pins in the form of Intel LGA (4094, Epyc), on-chip multiple dies, Epyc would replace Opteron brand for server market
Software Emulation ARM64		2017	Windows 10 on ARM64				Cooperation between Microsoft and Qualcomm bringing Windows 10 onto ARM64 platform with x86 applications supported by CHPE emulator starting from 1709 (16299.15)
Era		Release	CPU models	Physical Address Space			New features

Hello friends from Wikipedia German, the above table is provided for you all to evaluate, if you think it would improve the main article, then please translate it into German and bring it up, thank you in advance. Janagewen de (Diskussion)

Lizenznehmer

Es fehlt ein Abschnitt Lizenznehmer mit AMD und VIA.--58.9.71.227 16:11, 26. Jan. 2018 (CET)

Grafik bezüglich Darstellung der Register fehlt

Der Artikel ist noch deutlich ausbaubar. Es fehlt bspw. eine visuelle übersichtliche Darstellung der ganzen Register. Am besten wäre es, wenn man das in 3 Grafiken aufteilen würde. Einmal eine Grafik für die Register der 16 Bit Prozessoren, also 8086, 8088 und den 80286. Und dann eine Grafik für die Register der 32 Bit Prozessoren, also 80386, 80486, Pentium usw.. Und am Ende noch eine Grafik für die 64 Bit Prozessoren.

Der Grund warum das drei Grafiken sein sollen ist der, weil es so wesentlich übersichtlicher wird. So eine Registerübersicht eines x86-64 Bit Prozessors ist mit allen Erweiterungen nämlich schon ziemlich überladen und unübersichtlich. Die englische Wikipedia zeigt bspw. gut, wie man es eher nicht machen soll. Folgende Grafik halte ich bspw für sehr schlecht:

Negativbeispiel für eine schlechte Grafik. Da ist zwar alles drauf, was die x86-64 Architektur an Registern hat, aber besonders übersichtlich ist das nicht, wenn man sich erst einmal nur für das interessiert, was bspw. der 80386 hatte. Deswegen wären 3 Grafiken, für die jeweils die 16 Bit, 32 Bit und 64 Bit Prozessoren weitaus besser.

--IT-Compiler (Diskussion) 21:00, 6. Mär. 2022 (CET)

Control Register fehlt auch

Angaben zum Machine Status Code Register (ab 286er) und das Control Register (ab 386) fehlen ebenfalls. Wobei das auch in einen eigenen Artikel kann. Es sollte allerdings zumindest mal erwähnt werden. --IT-Compiler (Diskussion) 02:20, 7. Mär. 2022 (CET)

Überarbeiten

Der Artikel wurde von IT-Compiler zum Überarbeiten auf Wikipedia:Redaktion Informatik/Fehlende Artikel#Überarbeitungswünsche eingestellt.

@IT-Compiler: Bitte umbenennen in x86-Architektur und dann in die Abschnitte x86-16, x86-32 und x86-64 aufteilen. Außerdem fehlt noch eine Registerübersicht als Grafik für jede Unterarchitektur (also 16, 32 und 64 Bit). Siehe dazu auch (diese Diskussionsseite)

Ich finde prinzipiell auch, dass man den Artikel überarbeiten sollte. Allerdings weiß ich nicht, wo und wie man anfangen soll, ohne alles noch zu verschlimmern.

Außerdem habe ich eine grundsätzliche Frage: Warum aufteilen in x86-16, -32 und -64? Ist nicht der Befehlssatz grundsätzlich der gleiche, weil abgeleitet? Hinzu kommt, dass es die Artikel IA-32 (also x86-32) und x64 (also x86-64) bereits gibt. Dass man die Lemmata IA-32 – und nicht x86-32 – sowie x64 – und nicht x86-64 – verwendet, liegt daran, dass das die allgemein gültigen "gewachsenen" Bezeichnungen sind. Ja, gerade bei x64 könnte man vortrefflich streiten, nutzen doch auch viele Betriebssysteme bzw. Software allgemein auch die Bezeichnungen "amd64" und "x86-64", aber das hat in der Vergangenheit dann eben zu Problemen geführt, wenn ein Prozessor "Intel 64" nutzte, und sich Anwender nicht mehr sicher waren, was das "amd64" bei ihrem Intel-System zu suchen hatte... "x86-64" ist der Entwicklungsname von AMD64, weshalb von Windows auch "x64-basierter Prozessor" genutzt wird. Bei > 60% Marktanteil von Windows weltweit ist das wohl das beste Lemma. (Außerdem sollte man das Lemma nicht überbewerten, und WP:TF sollte man versuchen, zu unterbinden: weshalb die schönsten Bezeichnungen, die da wären x86-16, x86-32 und x86-64 leider gar nicht gehen...)

Mit anderen Worten: dieser Artikel, den man in x86-Architektur umbauen könnte/sollte, beschreibt die gesamte Architektur, während IA-32 und x64 die Unterarchitekturen beschreiben.

Also bitte nicht aufteilen.

‣Andreas•⚖ 22:42, 1. Mai 2022 (CEST)

Es geht um Unterabschnitte, also eine Gliederung. Das einführen von Unterabschnitten dient der Gliederung und historischen Entwicklung. Außerdem kann man dann verschiedene Registergrafiken für die jeweiligen Architekturerweiterungen erstellen. Im Prinzip geht es also um die wesentlichen Entwicklungsschritte der x86-Architektur, also vom 8086 (entspricht x86-16) zum 80386 (entspricht x86-32) und letzten Endes dann x86-64. <br>

Es ist richtig, dass es die Artikel IA-32 (also x86-32) und x64 (also x86-64) bereits gibt, aber dieser x86-Architektur Artikel soll ja auch nur ein übergreifender Artikel sein, der das Thema kurz anreißt und in die Details geht man dann in die entsprechenden anderen Artikel. Es reicht also für jeden wesentlichen Entwicklungsschritt 16 Bit, 32 Bit und 64 Bit ein kurzer eigener Unterabschnitt mit vielleicht 10 Zeilen Text + eine dafür gedachte Registergrafik dazu. In den Unterabschnitten verweist man dann nach dem groben Anriss auf die Detailartikel und die Registergrafiken sollen dann der visuellen Orientierung dienen. So eine überladene Grafik, wie ich oben beispielhaft aus der englischen WP verlinkt habe, wäre hier nämlich auch nicht dienlich. --IT-Compiler (Diskussion) 22:54, 1. Mai 2022 (CEST)

Verstehe ich, gleichzeitig ist es jedoch auch so, dass alle 8086-Register und Betriebsmodi auch in IA-32 und x64 vorhanden sind, weil jeder 32- und 64-Bit-x86-Prozessor auch ein vollwertiger 16-Bit-x86-Prozessor ist. Zumindest noch...

Außerdem ist es so, dass die Register des 8086 auch im 80386 noch vorhanden sind, es kamen nur welche dazu (keine weg). Genauso verhält es sich mit dem Opteron aka AMD64, wo etwas dazukam, aber nichts weg. Da das ganze aufbauend ist, wäre es redundant, die Informationen in allen Artikel aufs neue zu beschreiben, wenn sie im Kern auf alle drei "Bittigkeiten" (16-, 32- und 64-Bit-x86) zutreffen.

Die Begrifflichkeiten (die von mir stammen, und leider redundant im diesem Artikel und bei IA-32 sowie bei x64 zu finden sind) könnte man jedoch ein für alle Mal zusammenfassen, wenn dieser Artikel ein Über-Artikel werden würde.

Nur eine Frage noch: wie soll den der x86-16-Arikel eigentlich heißen? (Es gibt nämlich eigentlich keinen wirklichen Namen dafür... IA-16 vielleicht?)

‣Andreas•⚖ 23:11, 1. Mai 2022 (CEST)

Ja, aber genau diese Überladung soll ja vermieden werden. Ich finde, da der technische Detailaspekt gut in den anderen Artikeln beschrieben ist, sollte man hier eher eine geschichtliche Gliederung nutzen und dann ist das unterteilen sehr sinnvoll. Man könnte für den "x86-16" Artikel auch einfach IA-16 nehmen, was für Intel Architektur 16 Bit stehen würde. Die englische Wikipedia nutzt diesen Bezeichner ebenfalls, siehe: https://en.wikipedia.org/wiki/IA16 --IT-Compiler (Diskussion) 23:49, 1. Mai 2022 (CEST)

IA16 in der englischen Wikipedia ist aber eine Begriffsklärungsseite...

Es tut mir leid, aber ich bin der Ansicht, man sollte die Struktur der 16-Bit-x86-Architektur in diesem Artikel beschreiben, denn alle Erweiterungen bauen darauf auf. Dass IA-32 und x64 eigene Artikel sind, ist ja okay, und in denen sollten eigentlich nur die Unterschiede bzw. Erweiterungen beschrieben sein, was der Artikel IA-32 ja auch eindrucksvoll tut: (Abschnitt #Architekturmerkmale) Alle Register, einschließlich der Adressregister, wurden in dieser Architektur auf 32 Bits erweitert.

IA-16 ist eine retronyme Bezeichnung für das, was vor dem i386 kam, die (soweit mir bekannt) nicht einmal von Intel stammt, und die sich auch nicht eindeutig durchsetzen konnte. Somit ist auch unklar, ob der 16-Bit-Protected-Mode des 80286 nun dazugehört oder nicht... (Oder gar der veränderte Real Mode ab dem 80186.)

‣Andreas•⚖ 13:40, 2. Mai 2022 (CEST)

Nachtrag: Um es ganz klar zu sagen: x86 heißt die Architektur, die 16-, 32- und 64-Bit-Entwicklungen beinhaltet -- daher sollten alle Betriebsmodi und Register, ob nun 16-, 32- oder 64-Bit, auch im Artikel zur x86-Architektur abgebildet sein. Es gibt ja auch Überlappungen: der V86-Modus des i386 ist ein 16-Bit-Modus, der als Zusatz für den 32-Bit-Protected-Mode gedacht war. Der Compatibility Mode im 64-Bit-Long-Mode unterstützt nach wie vor 16-Bit- und 32-Bit-Protected-Mode-Programme, obwohl ein 64-Bit-Modus... ‣Andreas•⚖ 14:06, 2. Mai 2022 (CEST)

Alle Betriebsmodi und Register wären doch abgebildet, das habe ich ja oben geschrieben. Es geht hier um eine historische Gliederung, weil man so viel leichter von 16 Bit auf 32 Bit zu 64 Bit übergehen kann und das dennoch thematisch getrennt ist, wenn es untergliedert ist. Das was du willst ist, um mal eine Analogie zu nehmen, Eiscreme, Sauerbraten und heiße Suppe zusammen in einem Topf schön verrührt und das ist weder hilfreich noch didaktisch sinnvoll. --IT-Compiler (Diskussion) 15:57, 2. Mai 2022 (CEST)

Naja, vielleicht habe ich es auch nicht richtig verstanden, was du genau willst. Ich meine, dass es ja durchaus möglich ist, ein ursprünglich 16-Bit-x86-Programm als 32-Bit-Programm zu übersetzen, mit kleineren Anpassungen, siehe etwa hier (englisch): Box The long and short of it und Abschnitt Achieving the 32-bit blessing. – Recompiling 16-bit programs into 32-bit programs will frequently prove disappointing.

ARM gibt es ja auch als 32- und 64-Bit, so wie auch PowerPC. Wer Linux kenn, weiß, dass es vielfach (bei einfacheren Programme) möglich ist, diese als 32- oder 64-Bit-x86-Code zu übersetzen. Die Architektur, die ISA, ist dabei zwar sekundär (da das neben x86 auch z.B. für PowerPC, ARM, MIPS etc funktioniert), dennoch ist die Grundarchitektur von x86 im Großen und Ganzen beinahe identisch.

Wäre nicht eine Aufteilung in 1. Real Mode (nur 16-Bit), 2. Protected Mode (16-, 32-, 64-Bit), und 3. Long Mode (ebenfalls 16-, 32- und 64-Bit) sinnvoller?

Und ich habe immer noch ein Problem mit der Bezeichnung – dem Lemma. x86-16 gibt es nicht. x86-32 auch nicht. IA-32 ist ein Marketingname von Intel für i386 bzw. 32-Bit-x86. Nur x86-64 gibt es, allgemeiner ist aber eher x64 (nicht zuletzt wegen Windows > 60% Marktanteil). Lemmata sind wichtig (Belegpflicht) - auch, wenn es nicht so einfach ist, aber dann muss man sich zumindest in einer Diskussion einig werden und gute Argumente haben.

Wie gesagt, vielleicht reden wir ja aneinander vorbei?

‣Andreas•⚖ 16:50, 2. Mai 2022 (CEST)

Eine Aufteilung in 1. Real Mode (nur 16-Bit), 2. Protected Mode (16-, 32-, 64-Bit) halte ich nicht für sinnnvoll, da der 286er sowohl den Protected Mode kann, aber noch eine reine 16 Bit CPU ist. Wollte man Assembler programmieren und die x86 Architektur von Anfang bis Heute kennenlernen wollen, dann würde man sich die wesentlichen Architektursprünge ansehen und beim 8086 und seinen Registern anfangen, dann mit dem 386er und seinen zusätzlichen 32 Bit und Segmentregistern weitermachen, um dann noch später auf AMD64 überzugehen. So sind übrigens auch die ganzen alten Assemblerbücher aufgebaut, wo man noch für DOS sowohl 16 Bit, als auch unter Nutzung des Protected oder Unreal Mode in 32 Bit programmieren konnte oder für die Übergangszeit, wo das alles auch mit Windows NT und 95 anfing.

Die Zwischenschritte, wie der Protected Mode nach dem 8086 oder MMX beim Pentium MMX oder SSE beim Pentium 3 wenige CPU Generationen nach dem 386er würde man als als Nebensatz in den entsprechenden Abschnitten, also für ersteres 8086 und x86-32 für zweiteres einfügen. Und so stelle ich mir das vor. So wäre es am sinnvollsten und dann hätte man für jeden Abschnitt eine eigene Registergrafik und eine kurze Einführung, wobei die Details dann auf den weiterführenden Artikeln stehen, auf die dann in diesem Abschnitt natürlich verwiesen wird. Die einzelnen entsprechenden Register Grafiken könnte man in diesen weiterführenden Artikeln dann gleich weiternutzen. --IT-Compiler (Diskussion) 17:12, 2. Mai 2022 (CEST)

Zu den Begriffen. Wir können das auch umschreiben. Als Gesamtüberschrift könnte man "Geschichte" wählen. und diese Rubrik ist dann untergliedert in die "x86 und 16 Bit Ära", dann "x86 und 32 Bit Ära" und "x86 und 64 Bit Ära". Damit bräuchte man kein Lemma und es wäre dennoch klar ersichtlich, was damit gemeint ist. Und da aus dem Kontext klar ist, dass es hier um die x86 Architektur geht, könnte man das "x86 und" auch weglassen einfach die Gliederung "16 Bit Ära", "32 Bit Ära" und "64 Bit Ära" verwenden. --IT-Compiler (Diskussion) 17:19, 2. Mai 2022 (CEST)

Ich habe da ein Verständnisproblem, nämlich: Wie passt x32 da dazu? x32 (ABI) ist quasi IA-32 mit den doppelt so vielen Registern aus dem Long Mode, es ist also "64-Bit-Ära" in 32-Bit-Ausführung. x32-Programme waren bei der Hardware von ~2010 teils 30% schneller als 64-Bit-Programme (x64), weil eben die Speicheradressen nur halb so lang sind (und daher das Kopieren weniger lange dauert: ist ja nur mehr die Hälfte von 64-Bit-breiten Adressen) -- kommt ein Programm mit 4 GB Adressraum aus, ist das aber kein Problem.

Ist nicht -- demzufolge -- IA-32 und x64 gar nicht so verschieden? Und ebenso verhält es sich doch bei x86 16-Bit (80286) im Vergleich zu i386, denn der wesentliche Unterschied ist wohl eher Real Mode mit seinem 1-MB- und anderen Speicherlimits zu Protected Mode (ob nun segmented oder flat memory model, der 386 kann ja beides).

Das ist natürlich nicht Assembler-Level. Kann sein, dass in reinem Assembler der Unterschied zwischen 286 Protected Mode und 386 Protected Mode erkennbarer ist als in Hochsprachen, oder zwischen 32-Bit-Protected-Mode im flat memory model und 64-Bit-Long-Mode. Und x32 im Long Mode.

Noch eine andere Frage: Wir haben hier den Artikel x86-Prozessor. Wenn wir z.B. einen Artikel "Flugzeugtriebwerk" hätten... dann fänden wir dort aktuelle Angaben, und historische weiter unten. Und so ist es auch: Der Artikel Luftfahrtantriebe listet grundsätzlich die unterschiedlichen Arten auf, und z.B. unter Mantelstromtriebwerk findet man dann aktuelle Mantelstromtriebwerke -- nicht historische, die sind erst weiter unten (es gibt einen Abschnitt "Geschichte"). Also: Warum sollte der Aritkel "x86-Prozessor" bzw. "x86-Architektur" nicht die aktuellen Register usw. darstellen?

Das würde bedeuten, dass vieles aus dem x64-Artikel auch hier her müsste. Umgekehrt könnte man dann in einem geschichtlichen Überblick beschreiben, was in früheren Generationen alles anders war...

Mir jedenfalls erscheint die jeweilige Ära sehr stark mit den Betriebssystemen und allgemein der Software aus derselben Ära verknüpft zu sein... Vieles, was da eingebaut wurde, ist nur da, um Kompatibilität zu garantieren bzw. um den Übergang weniger "schmerzhaft" zu gestallten... (Siehe dazu z.B. auch Lab Notes über den 486 aus dem PC Magazine von Nov. 1990...)

‣Andreas•⚖ 18:34, 2. Mai 2022 (CEST)

Der 386 und alle nachfolgenden 32 Bit x86 CPUs haben 32 Bit breite Register. Das sind bspw. EAX, EBX, ECX usw.. Außerdem sind sie, wenn ich mich nicht irre vielseitiger einsetzbar. Diese Register enthalten auch die alten 16 Bit Register vom 8086 und 286er, also AX, BX usw, welche man Programmiertechnisch noch in AH und AL, für High und Low aufteilen kann um bspw. nur mit einem Byte (8 Bit) zu arbeiten, anstatt einem Wort (16 Bit). Außerdem kommen noch zwei zusätzliche Segmentregister FS und GS dazu, die der 286er noch nicht hatte. Das Flagregister ist auch erweitert und enthält weitere Zustände, z.B. einen Zustand für bspw. den Virtuellen 86 Mode.

Weil es diese Unterschiede gibt, ist es meiner Meinung nach schon sinnvoll, das in separaten Grafiken zu den Registern zu trennen, so dass man den Unterschied sofort sieht. Obige Grafik ist für 64 Bit CPUs, da wird das sehr unübersichtlich, wenn man nur wissen will, was bei den 16 Bit oder 32 Bit CPUs dabei war. Und die Register der FPU waren Teil der Co-Prozessoren und nicht einmal Bestandteil der CPUs. Erst mit dem 486er änderte sich das.

Gerade weil ich es nicht für sinnvoll halte, alles bis ins Detail, was in den 32 Bit und 64 Bit Artikel bereits erwähnt wurde, hier redundant noch einmal zu erwähnen, halte ich es für sinnvoller hier nur eine kurze geschichtliche Einführung zu machen und für Detailwissen auf die anderen Artikel zu verweisen. Wollte sich also jemand über die x86 Architektur informieren, dann würde er so nicht alles mehrfach und doppelt lesen müssen, wenn man die Redundanz weglässt und dadurch veringert sich auch die Wahrscheinlichkeit, dass sich Fehler einschleichen oder man unvollständige Artikel hat.

Zur Analogie Luftfahrtantriebe, die die unterschiedlichen Arten entsprechend quasi der 16 Bit, 32 Bit und 64 Bit Ära und wer es dann ganz genau wissen will, der klickt auf den Detailartikel der entsprechenden Art. Daher ist der Luftfahrtantriebe Artikel nur ein grober Überblick und so sollten wir das mit dem x86 Architektur Artikel auch machen. Die aktuellen Register würden dann ja beim Abschnitt 64 Bit dastehen. Das schöne wäre aber, der Abschnitt 16 Bit und 32 Bit hätte eine eigene Registergrafik und hätte die Register der 64 CPUs dann nicht und das sorgt für mehr Überblick.

Die Segmentierung ist auch in Hochsprachen bei der Nutzung des Compilers erkennbar. Manche C Compiler aus dieser Zeit konnten bspw. nur Binaries erzeugen, die aus 64 KiB Code und 64 KiB Daten entstanden, dafür wurden dann die beiden Segmente CS (Code Segment) und DS (Daten Segment), sowieso noch das SS (Stack Segment) für den Stack verwendet. Und C Compiler die mehr konnten, denen konnte man Parameter übergeben um bswp. ein Small oder Far Memory Model zu verwenden. Letzteres nutzte dann wie bei Assembler Code auch, Far Jumps in andere Segmente. Da der 8086 von Haus aus 4 hatte (CS, DS, SS und ES) und beim 386er noch 2 weitere dazu kamen (FS und GS) ging das. Dennoch war das für Leute, die von anderen Prozessoren her kamen, z.b. 64000 von Motorola oder professionelle Rechner aus dem Serverbereich ein Krampf. Wer mit einem C Compiler und dem Small Memory Modell also ein Array erstellen wollte, der musste darauf aufpassen, dass es in die 64 KiB passte. Das änderte sich alles erst mit dem 386 und den DOS Extendern und passenden neuen Compilern die den Protected Mode unterstützten, die es dann erlaubten ein flaches Speichermodell mit 32 Bit breiten Adressen zu nutzen. Das ging so weit, dass man, als die 386 für den Massenmarkt erschwinglich wurde und eine gewisse Verbreitung hatten, den 386er zur minimalen Systemanforderung machte und viele neuere DOS Programme gar nicht mehr auf den älteren CPUs liefen. Ab ca. 1993 stellte bspw. praktisch kein AAA Spielehersteller mehr Spiele für den 286er her. Den Aufwand machte man nur noch da, wo es sich finanziell rechnete. Z.B. manche Office Anwendungen, aber das änderte sich mit dem Wechsel zu Windows 3.x und später Windows 95, sowie dem starken Leistungszuwachs bei den CPUs in dieser Zeit dann auch recht schnell. --IT-Compiler (Diskussion) 19:20, 2. Mai 2022 (CEST)

Okay, offenbar kenne ich mich dann wirklich zu wenig damit aus. Ich möchte nur verhindern, dass man den Eindruck erhält, x86-16 (das ja nicht so heißt), x86-32 (das ja IA-32 heißt) und x86-64 (also x64) wären komplett unterschiedlich und hätten keine Gemeinsamkeiten. Denn das, was alle x86-Prozessoren als ISA eint, sollte eben in den übergreifenden Artikel.

Aber gut, wenn du das so siehst, nur zu. Vielleicht will sich ja sonst noch jemand dazu äußern.

Ich weiß immer noch nicht, wohin du im 16-Bit-Abschnitt verlinken willst...

1. 16-Bit-x86 (ab 8086), Abschnitt z.B. "x86 und 16 Bit Ära" (da fehlt die Durchkopplung) → Verlinkt z.B. mit {{Hauptartikel|...}} wohin?
2. 32-Bit-x86 (ab 80386), Abschnitt z.B. "x86 und die 32-Bit-Ära" (durchgekoppelt ;-) ) → Verlinkt zu IA-32
3. 64-Bit-x86 (ab Opteron), Abschnitt z.B. "x86 und die 64-Bit-Ära" → Verlinkt zu x64

Mir fällt jedoch gerade auf, dass in den Artikeln Intel 8086, Intel 80286 und Intel 80386 z.B. die Register bereits beschrieben sind.

Wie dem auch sei, ich weiß nicht wirklich inwieweit man das verändern kann, ohne das alles noch viel chaotischer zu machen als es ohnehin schon selbst ist (allein die Tatsache der verwirrenden Begriffe IA-16, IA-32 und IA-64 -- letzteres ist ja keine x86-Architektur -- und x86-16, x86-32 und x86-64 -- die es leider so nicht wirklich gibt bzw. die sich nicht breit durchgesetzt haben -- macht es schon von sich aus chaotisch genug...) Hinzu kommt, dass x86-16 und x86-32 überbewertet werden. Es ist nicht wirklich von Bedeutung, ob ein System für 16-Bit-x86 entworfen wurde, denn es ist eher wichtig, ob es auf einem 8088/8086, einem 80186, einem 80286 oder einem 80386 läuft. Dasselbe gilt für 32-Bit-x86: der i386 ist meist gar nicht so wichtig, und oft sogar falsch verwendet: einiges an Software, die i386 als 32-Bit-x86-Kennzeichnung verwendet hat, setzt in Wirklichkeit z.B. einen i486 oder einen Pentium voraus.

‣Andreas•⚖ 22:07, 2. Mai 2022 (CEST)

Zu 1. wenn es da keinen passenden Artikel geben sollte, müsste man den erstellen. Da der 8086 aber nicht viel enthält, kriegt man das vielleicht auch in diesem Artikel unter. Der Intel 8086 und falls nötig zusätzlich noch der Intel 80286 Artikel wäre auch eine Möglichkeit.

Eine Umbenennung des Artikels von X86-Prozessor zu x86-Architektur wäre schon ein Anfang. Ich selbst werde wahrscheinlich demnächst nicht zu diesem Artikel kommen und versprechen will ich auch nichts. Im Erstellen von SVG Grafiken bin ich auch nicht fit. Inkscape habe ich mir vor 3 Monaten mal angeschaut, aber da bin ich noch blutiger Anfänger. Da ich aber weiß, was in die Grafiken rein muss, werde ich die doch selber machen müssen.

Ja, letzteres ist richtig. Das ist historisch so gewachsen. Damals lief das alles noch auf einem i386. Vor allem im Open Source Bereich. Dann wurde die FPU zu einer Anforderung, die ein i386 ohne weiteres nicht hatte, der 387 Co-Prozessor musste ja dazu gekauft werden und schon liefen die Binaries nur noch auf 486er oder eben einem 386 mit zusätzlich in den Rechner eingebautem Co-Prozessor. Und dann kam der Pentium MMX mit seinen MMX Registern und später der Pentium 3 mit seinem SSE Register, das man dann dringend benötigte und schon lief die Software weder unter einem 386er noch unter einem 486er. Oftmals ist es aber so, dass das zur Compilezeit berücksichtigt werden kann und der Binärcode lediglich für die späteren CPUs compiliert wird, eine Compilierung für den 386 aber noch möglich wäre, womit der Bezeichner i386 immer noch die richtige Bezeichnung für den Quellcode ist, nur halten sich dann viele Distributionen beim Binärcode nicht daran und compilieren gleich für CPUs mit SSE, PAE und XD-Bit Unterstützung. In manchen Fällen fliegt der Support der alten CPUs dann aber doch raus.

Der 386er wird vom Linuxkernel bspw. nicht mehr unterstützt. Entsprechender Code wurde vor Jahren entfernt. Aber das ist der Kernel, da wird noch einiges mit Assembler programmiert, der dann natürlich an den entsprechenden Prozessor angepasst ist und bpsw. diese Erweiterungen direkt nutzen könnte. Code der in einer Hochsprache wie C vorliegt, kann man aber in der Regel problemlos für einen 386er compilieren. Im Regelfall ist dafür ja nur ein Parameter für den Compiler erforderlich, gegebenenfalls muss noch das Makefile angepasst werden. --IT-Compiler (Diskussion) 22:53, 2. Mai 2022 (CEST)