Diskussion:4-GB-Grenze

Man sollte dringend erklähren weshalb genau nur 4GB unter 32-bit möglich ist. Das mit den 2^32 ist ja ok, aber wer weiss den wie es ist. Die Adressen sind beschränkt, deshalb nur 4GB... aber kann dann der Prozessor nicht eifach 2 Schritte machen und so umgehen. Oder wie funktioniert das. Das sollte mal von einem "Spezialist" ganz genau erklärt werden.

Das wird im Artikel 32-Bit-Architektur nochmal genauer erklärt. Und die von dir Beschriebenen "Umgehungsmöglichkeiten" sind in den (verlinkten) Artikeln Address_Windowing_Extension und Physical Address Extension beschrieben. --P.C. ✉ 13:22, 10. Jul. 2007 (CEST)

Die 4GB Grenze existiert auf einem x86 System faktisch nicht. Der maximal addressierbare Speicher betrug schon beim 386er 64Terabyte - nur physikalisch konnte er nicht mehr addressieren da er nur 32 Adressleitungen kannte. Auch im Protected Mode setzt sich eine Adresse aus Segmentdeskriptor und Offset zusammen wobei der Offset auf 32Bit beschränkt ist - diese Segmentierung hat jedoch nichts mit der Katastrophe auf der x86 Plattform unter 16Bit unter DOS im REAL-Mode zu tun. Die meisten Programme sind aufgrund der Beschränktheit der Compiler auf 4Gb beschränkt, das diese oftmals im FLAT-Modell arbeiten und die Segmentzeiger einfach "festnageln". Zum derzeitigen Zeitpunkt reicht dies auch völlig aus. Bis wir Programme haben die echte 4GB benötigen wird der Markt 32Bit Systeme nicht mehr kennen. Sowohl die Prozessoren als auch die Betriebssysteme stellen gerade um. Schon heute ist eine Pentium CPU nicht mehr in der Lage ein einzelnes Byte zu Addressieren. Wird ein einzelnes Byte benötigt so liefert der Speicher stets das Quadwort ab der nächts unterhalb liegenden 8 Bytegrenze. Nur die obersten 28 Bit werden zur Adressansteuerung genutzt, die unteren 4 diesen der Selektion des einzelnen Bytes aus dem Quadwort. Da man aber nun 4 Adressleitungen frei hat, kann man diese einfach entsprechend verlagern und mit einem 32 Bit Bus einen effektiv 36 Bit breiten Bus bauen - der Pentium Pro war der erste Prozessor der das so machte. Der Speicher ist nicht mehr in Byte, sondern in Quadworten orgarnisiert. Ein Speicherzugriff sind nich 8, sondern stets 64 Byte. Die einzige Grenze welche die x86-32 Architektur kennt ist das bei einem Programmadressraum über 4GB eine Addressierung immer mit dem Umsetzen des Segmentzeigers verbunden ist - und dafür sind die meisten gängigen Compiler einfach zu faul.... (Der vorstehende, nicht signierter Beitrag stammt von Benutzer:PeeCee, 12:22, 10. Jul. 2007.)

Ganz versteh ich deine Argumentation nicht: wenn man die ersten 28 Bit für die Addressierung des Quadworts und die letzten 4 Bit für die Selektion des einzelnen Bytes verwendet, dann entspricht das doch im prinzip der Addressierung eines einzelnen Bytes. --MrBurns 17:30, 22. Dez. 2007 (CET)

Mir is übrigens grad ein kleiner Fehler in deinem Text aufgefallen, welchen ich vorher garnicht gemerkt hab: wenns wirklich so gemacht wird, wie du sagst, dann wir das einzelne Byte nicht aus einem Quadwort, welches ja nur 8 Byte lang ist, sondern aus einem 16-byte-Wort sellektiert (2^4=16). --MrBurns 07:34, 25. Jan. 2008 (CET)

Bitte verwechselt das Laden von Cache-Lines, erzwungenes Alignment udgl. nicht mit der programmseitigen Adressierung im logischen Hauptspeicher. Letzteres wird eher kompliziert (vor allem für den Compiler, aber nicht nur), wenn der Adressraum nicht mehr flach ist, und daher nicht mehr ein einzelnes Register zur Adressdarstellung ausreicht. Ich kann mich noch an die Verrenkungen mit den Speichermodellen von 8088 und 80286 erinnern... Sobald man andauernd zwischen Segmenten springen muss, ist das auch weniger performant, als gleich 64-Bit Adressen zu verwenden. --Mopskatze 01:06, 22. Feb. 2008 (CET)

Das Moorische Gesetz wird wahrscheinlich in ein paar Jahren außer Kraft treten (siehe im dazugehörigen Wikipedia Artikel), darum sollte dieser Artikel bedeutend verändert und verbessert werden! Auch die anderen, hier genannten Punkte, sollten miteingebracht werden. (Der vorstehende, nicht signierte Beitrag stammt von 20:59, 5. Feb. 2008 Benutzer:Ultio92.)

Ich habe den Artikel mal etwas überarbeitet. Der Artikel sollte jetzt der Wirklichkeit entsprechen. Die obrige Argumentation von PeeCee ist leider völlig falsch. Nicht der Datenbus ist auf (älteren, nicht x86-64) x86 Prozessoren 8, 16 oder 32 groß, sondern eine Cacheline. Die Segmentierung des Speichers auf dem x86 kann nicht dazu benutzt werden mehr als 4 GiB zu adressieren, selbst wenn PSE oder PAE aktiviert sind. PAE und PSE vergrößern nur den von der MMU adressierbaren, physikalischen Adressraum. Sie arbeiten auf Basis von Paging und haben garnichts mit Segmentierung zu tun. Die Segmentierung auf x86 Prozessoren ist ein Relikt aus 286 und DOS bzw. OS/2 Zeiten, der 286 hatte nur einen 16 Bit Protected Mode, der die Segmentierung brauchte, um 20 Bit = 1 MiB Speicher addressieren zu können (16 Bit Wordworte + 4 Bit durch Segmentierung). Später wurde die Segmentierung aus Gründen der abwärtskompatibilität beibehalten. Die in den für Segmentierung intern vom Betriebsystem benutzten Strukturen verwenden zur Adressierung nur 32 Bit, können die 4 GiB Grenze also nicht überschreiten. Der x86 erlaubt auch heute noch Byteweise Zugriffe, über ein spezielles Bit in einem Prozessorregister lässt sich jedoch ein Alignment von 16 Bit Speicherzugriffen auf 2 Byte Grenzen und von 32 Bit Speicherzugriffen auf 4 Byte Grenzen erzwingen. Ansonsten verwenden nur einige neuere SSE Instruktionen (Move Aligned Packed Single-Precision Floating-Point etc., siehe Intel Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 2A: Instruction Set Reference, A-M) ein erzwungenes Alignment von Daten. (Der vorstehende, nicht signierte Beitrag stammt von Benutzer:80.134.135.28, 02:35, 29. Mär. 2008)

Die Argumantation von PeeCee ist leider völlig richtig. Selbstverständlich kann die Segmentierung auf einem x86 genutzt werden um mehr als 4 GiB Speicher zu addressieren. Die Segmentierung im PMode ist eine völlig andere al im R-Mode und hat nichts, aber auch gar nichts mit dem "Unfall" im R-Mode zu tun! Ich bitte einmal sich die entsprechende Prozessordokumentation von Intel RICHTIG anzusehen. Wie sonst würde mein Linux-Rechner mit 8 GiB Speicher und einem P4 sonst so Rreibungslos funktionieren. Ein P4 erlaubt auch heute noch Byteweise Zugriffe - auf logischer Sicht (Programmierebene), nicht auf der Hardwareebene. Wird ein Byte gewünscht wird beim Speicherzugriff das gesamte 64 Bit Quadwort geholt und das Byte daraus selectiert. Die Adressleitungen A0 bis A3 gibt es nicht mehr.

Die von Ihnen geposteten Argument gelten für das Betriebssystem Windows - nicht für die 32Bit Architektur als solche! Es gibt nur zwei Limits bezüglich 4GB auf einer IA32: Ein einzelner Datenblock darf 4 GiB nicht überschreiten (maximale Größe einer Datenstruktur) und dieser Grenze gilt auch für den Code eines Threads.

Beschränkung auf 86er?

Gibt's einen Grund, die Begrenzung auf 4 Gigabyte addressierbaren Speicherplatz auf die 86er-Technik zu beschränken. Sie gilt doch faktisch für alle Prozessoren mit 32bit-Adressregistern, oder? Die physikalische Busbreite hat überhaupt nichts damit zu tun: Es gibt Verfahren, eine 32bit-Adresse mit nur 1 Leitung zu übertragen... Wofa07 02:38, 11. Aug. 2008 (CEST)

Ja, der Artikel ist derzeit sehr x86-lastig. Da kann man durchaus etwas überarbeiten. Und was die Busbreite angeht: Bezeichnen wir doch einfach die Breite der Adressregister als "logische Adressbreite". Wie die Adressen dann physisch zum Arbeitsspeicher übermittelt werden (32 bit parallel, byteweise, oder bitweise) spielt für das Problem ja in der Tat keine Rolle. --RokerHRO 11:25, 11. Aug. 2008 (CEST)

Erledigt. :-) --RokerHRO 15:09, 13. Okt. 2009 (CEST)

Paging (Swap)

Was hat das mit der 4-GiB-Grenze zu tun? Zum einen ist Paging – im Gegensatz zur 4-GiB-Grenze – nichts Spezifisches für 32-Bit-Architekturen, und es dient auch nicht der Überwindung der 4-GiB-Grenze: Weder kann mit Paging ein Prozess einen Adressraum größer als 4 GiB ansprechen, noch kann ein 32-Bit-Kernel damit mehr als 4 GiB physischen RAM ansprechen. Letzteres ginge allenfalls theoretisch, etwa wenn ein 32-Bit-Betriebssystemkernel unter einem 64-Bit-Hypervisor liefe, der den Speicher jenseits der 4-GiB-Grenze dem Gastsystem als "virtuelle Festplatte" zur Verfügung stellt, in das das Gastsystem dann "swappen" kann. Hab sowas in der Praxis aber noch nicht gesehen, auch ist das nicht der Hauptzweck von Paging/Swapping. --18:23, 19. Dez. 2008 (CET)

Unter Win 2k/XP/Vista x32/7 x32(?) kann man auch mit PAE weniger als 4GB physiklaischen Speicher ansprechen (aus Gründen der Trieberkompatibilität, siehe en:Physical Address Extension), der virtuelle Speicher, also die Summe der Größen von physikalsichem Speicher und Swapfile kann jedoch 4GB überschreiten. --MrBurns 00:43, 14. Okt. 2009 (CEST)

PAE ist so oder so auch in einem Computersystem mit weniger als 4 GB wikt:physischen Speicher sinnvoll, nicht nur für eine einheitliche Treiber-Schnitstelle. Nur mit PAE ist es z.B. möglich, das NX-Bit-Feature auszunutzen. Es ist jedoch kein PAE nötig, wenn die Summe aus physischem Speicher und Swapspeicher 4 GB übersteigen soll. Das konnte Linux z.B. schon seit Ewigkeiten (lange bevor es PAE überhaupt gab). Wenn MS Windows dafür PAE braucht, ist das eine (gewollte?) Einschränkung dieses Betriebssystems. --RokerHRO 08:53, 14. Okt. 2009 (CEST)

Hab ich auch nicht behauptet, ich ahb nur behauptet, dass man unter Win x32 auch mit PAE keinen physischen Speicher von über 4GB ansprechen kann und deshalb unter Win x32 die Swaqpfile braucht, um die 4GB-Grenze zu umgehen. --MrBurns 12:40, 14. Okt. 2009 (CEST)

Ah, okay, dann hatte ich dich missverstanden. :-) Wobei man aber den Swap nicht im RAM jenseits der 4-GB-Grenze anlegen kann (a la Ramdisk), außer, man schiebt einen Virtualisierer unter das Betriebssystem, das diesem eben dann nur noch 3 oder 4 GB RAM und den Rest als (virtuelle) Festplatte vorgaukelt. :-/ --RokerHRO 13:17, 14. Okt. 2009 (CEST)

Ja, aber man kann die Swapfile wie zusätzlichen RAM nutzen. Natürlich wirkt sich da negativ auf die Performance aus, da HDDs viel langsamer sind als der RAM, aber es ist nicht so schlimm, wie man vermuten würde, weil die Speicherverwaltung von Windows intelligent genug uist, die häufiger gebrauchten Daten trotzdem im RAM zu halten und nur weniger häufig gebrauchte Daten auszulagern. Für bestimmte Tätigkeiten wie z.B. spielen ist diese Methode der "Speichererweiterung" aber ungeeignet.--MrBurns 13:20, 14. Okt. 2009 (CEST)

1 Byte pro Adresse?

Das mit einem 32 Bit Adressbus maximal 2^32 = 4'294'967'296 Adressen ansprechen kann habe ich begriffen. Aber wieso entsteht dadurch die 4 GB-Grenze? Sind in einer einzelnen Adresse nicht auch 32 Bit = 4 Byte Daten gespeichert? Somit könnte ich 2^32 x 4 Byte an Arbeitsspeicher haben, das wären dann 4'294'967'296 x 4 Byte = ca. 17 GB ... aber wahrscheinlich übersehe ich da einen Fehler, oder wie ist das???
-- 10:35, 17. Feb. 2009 --

Auf heutigen Prozessorarchitekturen kann man jedes Byte im Hauptspeicher einzeln adressieren, jedes Byte im Hauptspeicher hat damit seine eigene Adresse. Natürlich können die CPUs auch 16- und 32-Bit-Zugriffe, also 2 oder 4 Bytes auf einmal (mit einem Buszyklus) ansprechen, das ändert aber an der byteweisen Adressierung nichts.

Also: Ein 32-Bit-Zugriff auf die Adresse 100 greift auf die 4 Bytes an den Adressen 100, 101, 102 und 103 zu.

(Für CPUs, die 64-Bit-Speicherzugriffe können, sind es eben bis zu 8 Bytes auf einmal, auf die zugegriffen werden kann.)

--RokerHRO 14:42, 17. Feb. 2009 (CET)

Verschieberei

Was soll die Verschieberei? Hat wieder jemand langeweile? -- 87.144.95.47 22:58, 14. Jan. 2010 (CET)

Das Frage ich mich auch - es sind eindeutig 4 GiB 4 x (2^30) (bzw. 2^32) und nicht 4 GB, also 4 x 10^9 --suit 10:27, 15. Jan. 2010 (CET)

Wir hatten diese Diskussion auch schon ca. 2^30 mal. GB ist nicht eindeutig definiert und kann auch 2^30 Bytes bedeuten und die GiB-Notation ist unüblich. Außerdem wurde durch ein Meinungsbild beschlossen, GiB nicht mehr zu benutzen. --MrBurns 10:39, 15. Jan. 2010 (CET)

Du sagst es, die GB ist nicht eindeutig - GiB ist sehrwohl eindeutig. Gemäß dem Meinungsbild wurde sinnvollerweise beschlossen, die Präfixe kontextabhängig zu verwenden - es wurde nicht beschlossen, sie nicht mehr zu verwenden - verbreite bitte keine Unwahrheiten. In diesem Artikel ist der Kontext Eindeutig die Begrenzung von 4 x 2^30 bzw. 2^32 Byte. Darum ist Gibi exakt, Giga unscharf. --suit 11:31, 15. Jan. 2010 (CET)

... und selbst wenn man das Ergebnis des MB so interpretieren könnte wie es MrBurns oben tut, wäre es von einem enzyklopädischen Standpunkt nicht möglich, eine von allen einschlägigen Normungsorganisationen beschlossene Einheit zu verbieten; genau so wenig wie man die Verwendung des Watt (Kilowatt) als Leistungsangabe in KfZ-Artikeln verbieten könnte, nur weil alle Welt nach wie vor von PS spricht. Argumente rauf und runter sowie Links zu dem Thema gibt es auf meiner Benutzerseite. Mit freundlichen Grüßen, Theoprakt 16:22, 15. Jan. 2010 (CET)

Es hat doch keinen Sinn, das Meinungsbild jetzt mittels diverser Spitzfindigkeiten nach eigenem gusto auslegen zu wollen. Der Grundtenor der breiten Mehrheit im Meinungsbild ist kibi go home, und danach haben wir uns zu richten.

Selbst wenn man das anders sieht, geht aus dem genauen Wortlaut des Meinungsbildes zumindest hervor, daß die traditionelle Notation weiter verwendet werden soll und keinesfalls falsch ist. Edits, die lediglich auf die ungebräuchliche Notation umstellen, stellen damit keine Verbesserung des Artikels dar und haben zu unterbleiben. Ist sich der Autor dessen bewußt, handelt es sich schlicht um Vandalismus. Deshalb habe ich diesen Edit revertiert.

Nebenbei bemerkt ist die aktuelle Version falsch, denn veraltet ist die klassische Notation keineswegs, und die dort genannte Quelle gibt das auch nicht her. --Dc2 21:10, 15. Jan. 2010 (CET)

Das sind allerdings keine Spitzfindigkeit, wenn man hier feststellt, das 4 GB unscharf wäre. Es geht hier konkret um 2^32, und im Zusammenhang mit diesem Artikel ist es auch wichtig, dass es nicht 4*10^9 ist, dass ist immerhin ein Unterschied von 7,4% und damit für diesen Artikel signifikant, da es hier konkret um eine Grenze geht und das keine "Nebeninfo" ist. Wie man das jetzt im Detail löst, ist mir dann eigentlich ziemlich egal. Ich stimme dir jedenfalls zu, dass 4 GB nicht veraltet ist, es sind halt 2 parallele Sichtweisen, die jenachdem in welchem Bereich man sich befindet beide üblich sind. Das ändere ich erstmal. Ionenweaper 22:05, 15. Jan. 2010 (CET)

Masn kanns ja auch ganz einfach lösen, indem man schreibt 4GB (2^32 Bytes) oder 4Gb (4*2^30 Bytes). Damit ist auch ohne die unübliche GiB-Notation klar, was gemeint ist. --MrBurns 10:06, 16. Jan. 2010 (CET)

So einfach und so sinnvoll wie ein Nagel im Kopf. Vor allem aber geht es bei Masseinheiten nicht pluralistisch zu wie in der Domaene der Geistes- und Kulturwissenschaftler, wo eine postmoderne Ansicht gleichberechtigt neben einer anderen steht. "Ueblich" und "unueblich" sind in diesem Zusammenhang voellig irrelevante Konzepte. Gueltig und richtig sind statt dessen jene Masseinheiten, die von den international anerkannten Gremien beschlossen wurden. Andere Masseinheiten oder abweichende Verwendungen sind ungueltig und falsch, auch wenn man sie noch jahre-, wenn nicht jahrzehntelang in Buechern, auf Produktbeschreibungen und in Notizen alternder IT-Angestellter finden wird. -- Theoprakt 10:53, 16. Jan. 2010 (CET)

Blödsinn, unter Normung steht eindeutig, dass diese nicht verpflichtend ist ("Wer Normen anwendet, folgt Empfehlungen, die von Kreisen der Fachwelt aufgestellt wurden. Ihr Zustandekommen und ihre Anwendung qualifiziert sie als anerkannte Regeln der Technik."). Das SI-Sytem ist gesetzlich vorgeschrieben in den Naturwissenschaften, aber nur für physikalische Einheiten und auch nur für Gesetzestexte etc. Sonst kann im Prinzip jeder verwenden, was er will. Nur wird in den Naturwissenschaften einheitlich das SI-Sytem verwendet, aber für den diese neuen Binärpräfixe gilt das nicht. Ich werde nochmal revertieren udn shclage ein Vollsperrung vor, bis die Angelgenheit geklärt ist. --MrBurns 12:04, 16. Jan. 2010 (CET)

Dein veralteter Wissensstand, Deine Lernunwilligkeit/unfaehigkeit und Deine dilettantischen Ansichten zu den Begriffen "Norm" und "Empfehlung" sind Dein Privatproblem. Mit Sicherheit sind sie keine akzeptable Grundlage fuer enzyklopaedische Arbeit. Sie per Editwar entgegen aller genannten Quellen und Argumente durchsetzen zu wollen ist Vandalismus. -- Theoprakt 14:10, 16. Jan. 2010 (CET)