Diskussion:Befehlssatzarchitektur
Erste Anmerkung (oder eigentlich Anfrage)
BearbeitenEs gibt den Stammbaum der Programmiersprachen [1]. Gibt es sowas auch für ISAs? --84.56.129.64 00:41, 5. Feb. 2007 (CET)
- Mit (der amerikanischen [Mehrzahl-]Abkürzung oder, wie es hier nebenan, gegenwärtig, meiner Ansicht nach noch immer unnötig fremdverschwurbelt heißt, mit ihrem Akronym) „ISAs“ meinst du wohl (einen Stammbaum der) Befehlssätze. Und ja, sicher gibt es dazu wenigstens auch einen Stammbaum, immerhin hat jeder Hersteller (also bspw. Intel, ARM oder [früher] auch [mal] Sun) seine eigene Enzwicklungsgeschichte, was die zugehörigen Rechenwerke (oder, denglisch, Prozessorarchitekturen) angeht. Ich schätze aber mal, daß du dazu ein (schon vorgefertigtes) Bild haben möchtest (oder damals, 2007, wolltest), was mir hier, in der eigentlich ja deutschsprachigen Wikipedia, bisher aber nicht bekannt ist. Vom Grundgedanken her (also im Sinne der Wikipedia) könnte es aber mal wohl recht nützlich sein, auch diesen (geschichtlichen) Teil mal (in einem ähnlich übersichtlichen Bild, wie auch dort ← wohl nur noch ansatzweise erkennbar, noch einigermaßen übersichtlich) aufzuklären und (dabei) ggf. aufzuarbeiten. Mit lieben Grüßen. -- 78.55.91.88 13:20, 25. Jan. 2025 (CET)
Umbenennen
BearbeitenDas deutsche Wort für ISA lautet Befehlssatzarchitektur. Sollte man den Artikel nicht auch dahingehend umbenennen? --Strimo 16:17, 26. Mär. 2007 (CEST)
- Das möchte ich unterstützen, weil insbesondere die Abkürzung ISA ja ganz andere Assoziationen, nämlich ISA-Steckplätze im alten PC, hervorruft. --PeterFrankfurt 17:10, 26. Mär. 2007 (CEST)
- Verschiebung erledigt. Habe den Artikel im Zuge der Anpassung auf den neuen Namen grundlegend überarbeitet. Ich hoffe, er bietet jetzt eine bessere Grundlage für Erweiterungen. Ich bin mir sicher, dass zu dem Thema noch einiges zu sagen ist. --Ruscsi 21:45, 8. Jun. 2007 (CEST)
Operandenanzahl
BearbeitenDer Abschnitt "Operandenanzahl" ist inhaltlich falsch. Die richtige Version ist u.a. in der englischen Wikipedia Instruction_Set_Architecture#Parts_of_an_instruction zu finden. Gezählt werden nicht die Speicherzugriffe, sondern die "operands explicitly specified in instructions". Also natürlich auch alle Register. Das einzige, was nicht gezählt wird, ist die implizite Stack-"Adresse".
In der in diesem Abschnitt zitierten Quelle werden die Operanden übrigens auch nach dem richtigen Prinzip gezählt. (nicht signierter Beitrag von 217.83.39.103 (Diskussion) 21:17, 28. Jun. 2011 (CEST))
- Also sorry, Zitat aus jener Quelle:
Die Ein-Adress-Maschine (auch AKKU-Maschine genannt) - Ein spezieller festgelegter Speicherort, der Akkumulator, enthält immer den 1. Operanden und nimmt das Ergebnis auf - Akkumulator kann eine reservierte Arbeitsspeicherzelle sein, oder ein Register im Prozessor Befehlsbeispiel: Akku:=Akku+Betrag(222)
- Der zählt den Akku (bitteschön ein Register) nicht als "Adresse". --PeterFrankfurt 02:25, 29. Jun. 2011 (CEST)
Um noch einmal die englische Wikipedia zu zitieren: "Most instructions specify a single explicit right operand [...] with the implicit accumulator as both destination and left (or only) operand". Es werden die expliziten und nicht die impliziten Register gezählt. Deswegen ist die Akku-Maschine eine 1-Adress-Maschine. --217.83.45.182 07:43, 7. Jul. 2011 (CEST)
- Ich kann nicht erkennen, wie Du das aus diesem Zitat herausliest. Das steht da nicht drin. --PeterFrankfurt 01:40, 8. Jul. 2011 (CEST)
- Ich würde auch sagen, es ist falsch, zu behaupten, es würden Speicherzugriffe gezählt. Vor allem, weil es keinen Sinn ergibt. Beispiel: 8086 und da dann z.B.
rep movsw
. Der Befehl hätte ja bis zu 2^16 Operanden! Andererseits (immer noch x86): es gibt keinen Befehl, der explizit mehr als einen RAM-Operanden nimmt; außerdem: es gibt keine Befehle mit 3 expliziten Operanden (egal ob Register oder Speicher). → x86 ist als 2-Adress-Maschine zu klassifizieren. Man bemerke auch, dass es primär um den Befehlssatz geht, und zwar vor allem um die Kodierung der Befehle, nicht ihre Semantik. --Daniel5Ko 02:45, 9. Jul. 2011 (CEST)- Aber x86 taugt auch hier nicht als allgemeingültiges Beispiel, weil er eben keinerlei 3-Adress-Befehle hat. Das haben anscheinend vor allem sehr alte Mainframe-CPUs, wenn ich es richtig sehe, mit denen ich mich ansonsten auch kaum auskenne. Insofern also lieber nicht zu sehr vom x86 ausgehen. --PeterFrankfurt 23:46, 9. Jul. 2011 (CEST)
- Das war ja nur mal ein Beispiel, das besonders seltsam ist.
- Aber hier mal ein zufällig ausgewähltes Buch: [2]
- Das spricht an der Stelle eigentlich fast nur von Registern. Ich konnte zwar nicht genug in der Vorschau sehen, aber ich vermute mal ganz stark, dass da nichts gebastelt wird, was z.B. bei 3-Adress-Befehlen überall echte Speicheroperanden möglich macht.
- Anderes Buch: [3]
- Dort wird explizit verlangt, dass eine k-Adress-Architektur wirklich k Speicheroperanden ermöglicht. Aber das Buch heißt auch "Embedded systems and computer architecture". Bei kleinem Adressraum und genügend langsamem und registerarmem Prozessor (also eben embedded oder vor langer Zeit) macht es auch einigermaßen Sinn, das überhaupt in Erwägung zu ziehen. Bei Prozessoren für z.B. heutige Desktop-PCs führt diese Forderung aus Performancegründen nur dazu, dass alle Befehlssatzarchitekturen 1-Adress-Architekturen sind, was der Artikel ja im Moment auch schon sagt. Man verliert eine durchaus sinnvolle Designentscheidungsdimension.
- Es scheint also in etwa so zu sein: beide Bezeichnungsweisen sind üblich. Was ihnen gemeinsam ist, ist die ermöglichte explizite Angabe von (bis zu) k Operanden in den Befehlen.
- (PS: load/store-Befehle müssen in beiden Fällen separat von den anderen behandelt werden, denn 0-Adress-Architekturen definieren beide Bücher - was ohne die Separation keinen besonders interessanten Rechner ergeben kann)
- --Daniel5Ko 01:10, 10. Jul. 2011 (CEST)
- Interessant, das erste Zitat behandelt Register und Speicherzugriffe gleichberechtigt, während das zweite explizit "memory addresses" erläutert. Dass da embedded Prozessoren erwähnt werden, sollte nicht groß stören, bis auf die notorische Ressourcen-Enge sind mir keine prinzipiellen Unterschiede im Befehlssatz geläufig (selber jahrelang puren 6502-Assembler für Automotive-Steuergeräte geschrieben). Also langsam komme ich mit der Einschränkung auf RAM-Zugriffe ins Wanken. --PeterFrankfurt 23:38, 10. Jul. 2011 (CEST)
- Gut. Nun müssen wir "nur noch" überlegen, wie wir diesen in der Realität praktizierten Teil korrekt und verständlich und ohne irreführende Widersprüche im Artikel unterbringen. :) --Daniel5Ko 01:16, 11. Jul. 2011 (CEST)
- Viel einfacher wird es ja nicht. Denn wenn ich es richtig sehe, zählt der reine Akku weiterhin nicht, sonst könnte es ja keine 1-Adress-Befehle geben, die einen Speicherinhalt in den Akku laden. Sowas zählt meiner Beobachtung nach als 1-Adress- und nicht als 2-Adress-Befehl, zumindest solange man den Akku im Befehl nicht ausdrücklich als von der Befehlsmnemonik separierten Operand angeben muss (obwohl das ja wiederum nichts am Prinzip ändert, u. a. weswegen ich dachte, mit der Einschränkung auf Speicherzugriffe eine klarer nachvollziehbare Definition zu verwenden). Ich hoffe, alle Klarheiten beseitigt zu haben. --PeterFrankfurt 02:08, 12. Jul. 2011 (CEST)
- Dass irgend etwas einfacher wird, hat ja niemand behauptet. Ich schlage vor, wir suchen unabhängig voneinander noch ein paar Quellen, und wenn jemandem einfällt, wie man die verschiedenen, scheinbar auch Mode-abhängigen, Definitionen leicht verständlich unter einen Hut bringen könnte, schreibt er's halt in den Artikel.
- Noch 'n Bissl Feedback zum Rest deines Diskussionsbeitrags:
- Weiter oben schrub ich schon, dass es wahrscheinlich sinnvoll ist, load/store-Befehle als separate Klasse anzusehen. Stichwort 0-Adress-Zeug. Und wenn ein Akku-Register gegenüber anderen Registern ausgezeichnet ist und völlig anders behandelt wird, zählt er natürlich nicht als "Adresse".
- Mit Mnemonics sollte man vermutlich überhaupt nicht argumentieren. Ich denke, das Binäre, also die Ausgabe eines Assemblers, bzw. der Programm-Input an die CPU, ist das entscheidendste und sinnvollste, wenn man schon so eine Klassifizierung vornehmen will.
- --Daniel5Ko 02:12, 13. Jul. 2011 (CEST)
- Ich würde auch sagen, es ist falsch, zu behaupten, es würden Speicherzugriffe gezählt. Vor allem, weil es keinen Sinn ergibt. Beispiel: 8086 und da dann z.B.
- Ich kann nur nochmal ausdrücklich dem ersten Beitrag in diesm Abschnitt zustimmen: Der Abschnitt "Operandenanzahl" ist inhaltlich falsch. Er sollte dringend überarbeitet werden. Leider habe ich dazu noch keine Zeit. Sowohl die Beschreibung als auch die Wertung sind falsch. Da ich oft meine Studenten auf Wikipedia-Artikel verweise, muß ich hier immer ausdrücklich vor diesem Abschnitt warnen. (Vielleicht komme ich nächstes Jahr mal dazu hier auch Inhaltlich etwas beizutragen)
Virtuelle Maschine vs. Emulator
BearbeitenDie Bezeichnung Virtuelle Maschine im Abschnitt Virtuelle Maschine ist meiner Meinung nach irreführend, es fehlt zudem auch komplett der Beleg. Eine CPU, die rein in Software implementiert wurde nennt man Emulator. Eine Virtuelle Maschine ist hingegen eine Software, die eine bestehende Virtualisierungsinfrastruktur echter Hardware nutzt, also einem physikalisch vorhandenen Prozessor, wenn dieser eine Virtualisierungsinfrastruktur bietet. Üblich ist daher, dass sie nur dessen Befehlssatz (ISA) beherrscht. Ein Emulator implementiert hingegen selbst den Befehlssatz in Software und kann daher auf jeder Prozessorarchitektur laufen, für die der Code des Emulators compiliert oder geschrieben wurde.
Beispiel:
Eine Virtuelle Maschine für den x86 Befehlssatz kann es daher nur auf x86 Prozessoren mit x86-Virtualisierung Funktion geben. Auf Intel CPUs wäre das bspw. VT-x.
Will man x86 Programmcode auf einem anderen Prozessorarchitektur ausführen, z.B. ARM, MIPS oder 68K, so benötigt man dafür einen Emulator. Dort gibt es keine x86 Virtualisierung und daher auch keine Virtuelle Maschine für x86 Programmcode.
Zu beachten ist, dass es Software gibt, die sowohl Virtuelle Maschine als auch Emulator sein kann. Der Emulator QEMU ist hierfür ein Beispiel. Zur Nutzung im Virtuelle Maschine Modus ist allerdings ein Prozessor mit entsprechender Virtualisierungsfunktion erforderlich. --84.158.118.103 01:08, 22. Jan. 2025 (CET)
- Nur teilweise richtig. Eine Virtuelle Maschine für x86 kann auch auf x86-Hardware ohne Hardware-Virtualisierungsfunktionen funktionieren, dann emuliert die entsprechende Software die Befehle nicht, sondern führt Ring-3-Befehle direkt aus (daher kein Emulator), was schneller ist. Ring-0-Befehle hingegen müssen "transponiert" (das korrekte Wort ist sicher anderes... "überführt" vielleicht?) werden, entweder auch in Ring 3 oder z.B. in Ring 2 oder Ring 1. Derart Virtuelle Maschinen waren in der Anfangszeit vielfach genutzt, da Emulation "zu teuer" für die Performance gewesen ist (heißt: zu langsam). QEMU hatte z.B. das KQEMU-Kernel-Modul (vor Version 0.11, also sehr sehr lange her), das auf Hardware wie damals üblichen Pentiums, die keine x86-Virtualisierungsfunktionen hatten, eine entsprechende Beschleunigung brachte. Siehe z.B. https://wiki.qemu.org/Documentation/KQemu. ‣Andreas•⚖ 15:56, 22. Jan. 2025 (CET)
- Das sind Kleinigkeitendetails, um die geht es hier aber nicht. Mir geht es hier um fremde Architektur = Emulation erforderlich und dass diese Emulation keine Virtuelle Maschine ist. --84.158.118.103 03:30, 23. Jan. 2025 (CET)
- Okay. Dann ein anderes Beispiel: die Java Virtual Machine, kurz: JavaVM. Der Zwischen(byte)code ist auf keiner in Hardware gegossenen Architektur lauffähig. Auf jeder Architektur läuft dieser Java-Bytecode jedoch auf der JavaVM ab, wo der Zwischencode in von der jeweiligen Architektur verstandenen Maschinencode übersetzt wird.
- Das Problem ist, denke ich, dass die Definition dessen, was eine VM ist, sehr schwammig ist. Siehe auch: Virtuelle Maschine #Typen virtueller Maschinen.
- ‣Andreas•⚖ 17:57, 23. Jan. 2025 (CET)
- Die JVM hat nur den Namen VM. Streng genommen wird der Bytecode vom Just in Time Compiler in nativen Code übersetzt und dann nativ ausgeführt. Es ist also keine VM. Und vor den JiT Compilern wurde der Bytecode in einer Emulation ausgeführt.
- So wie es im Artikel steht ist es einfach falsch. Emulator wäre das korrekte Wort, auch vom Kontext her. --84.158.118.103 19:56, 23. Jan. 2025 (CET)
- Nun ja, "prozessbasierte virtuelle Maschinen" sind aber im Artikel Virtuelle Maschine #Typen virtueller Maschinen belegt. ‣Andreas•⚖ 22:00, 23. Jan. 2025 (CET)
- Der Begriff " prozessbasierten virtuellen Maschinen" ist nur ein anderes Wort und ein schlechter und anderer Bezeichner für das Wort Emulator, was es letzten Endes ja ist. Und ob man auf einem Emulator ganze Betriebssysteme hostet oder nur einzelne Anwendungsprozesse, oder den Binärcode mithilfe eines JIT Compilers in nativen Binärcode übersetzt macht hier keinen Unterschied. --84.158.118.103 23:12, 24. Jan. 2025 (CET)
- Wikipedia:Keine Theoriefindung – klar kann ich persönlich das so sehen, dass eine "prozessbasierte Virtuelle Maschine" keine wirkliche Virtuelle Maschine meiner Definition und Wahrnehmung wäre, und daher eigentlich ein Emulator.
- Darf man das in den Artikel übernehmen? Nein, weil das eine Meinung ist, und damit das Gegenteil von bekanntem Wissen, das ja auch belegt und somit nachvollziehbar ist. ‣Andreas•⚖ 12:35, 25. Jan. 2025 (CET)
- Was soll der Einwurf mit Theoriefindung. Was ich schrieb ist keine Theorie, sondern Fakt. Überlege dir mal worum es in dem Artikel geht und beachte den Kontext des Artikels. Der Kontext ist nicht eine Befehlsarchitektur auf der identischen Befehlsarchitektur zum Laufen zu bringen, sondern, abgesehen von der nativen Ausführung, wie fremde Befehlsarchitketuren auf einer anderen Befehlsarchitekturen zum Laufen gebracht wird und das geht eben nur mit einem Emulator, weswegen das Wort "Virtuelle Maschine" falsch ist. --84.158.118.103 23:45, 25. Jan. 2025 (CET)
- Ich glaube, da hast du nicht verstanden, was "Theoriefindung" bedeutet. Es ist deine Theorie (der Begriff im Volksmund, nicht in der Wissenschaft), dass das so sei. Denn die Fachbücher von Leuten, die sich damit beschäftigten, sagen etwas anderes. Das bekannte Wissen, um das es der Wikipedia als Enzyklopädie geht, steht also im Gegensatz zu dem, was du hier als Fakt verkaufen willst.
- Also nochmal: zeige mir deinen "Fakt" in einem, besser mehreren Fachbüchern zu dem Thema. Dann können wir weiterreden, denn dann haben wir eine Basis dafür.
- Bis dahin steht mein Einwurf.
- ‣Andreas•⚖ 11:07, 26. Jan. 2025 (CET)
- Es ist eben nicht meine Theorie, sondern technische Realität. Nenne mir mal bitte eine Virtuelle Maschine für auszuführenden Code mit einer anderen ISA, als der, auf dem diese VM ausgeführt wird und die kein Emulator, Interpreter oder Übersetzer ist. Und komme mir nicht mit der JVM, denn dass die JVM nur dem Namen nach VM heißt und technisch wegen dem JIT streng genommen keine VM ist, sondern ein Übersetzer und wenn kein JIT in der Implementierung verwendet wird, es dann ein Emulator oder Interpreter ist, das habe ich dir ja schon oben erklärt.
- Im wissenschaftlichen Terminus verwendet man die Begriffe Übersetzer (Translation) und Interpreter.
- Beim ersteren wird ein Programm, dass in einer anderen ISA als der ausführenden Maschine geschrieben wurde, in die ISA der ausführenden Maschine übersetzt und damit nativ mit der ISA der ausführenden Maschine ausgeführt. Das ist das, was der JIT bei der JVM macht.
- Beim zweiteren wird ein Programm, das in einer anderen ISA als der ausführenden Maschine geschrieben ist, jeder Befehl einzeln in Software dekodiert und interpretiert und dann führt der Interpreter den eigentlichen Befehl nativ aus.
- Der Terminus "Emulation" kommt in den meisten Büchern zum Thema Rechnerarchitektur deswegen nicht vor, weil es sich hier um Anwendungssoftware handelt und nicht um Hardware und die beiden übergeordneten Begriffe Übersetzer und Interpreter das genauso abdecken. --84.158.118.103 23:45, 26. Jan. 2025 (CET)
- Was soll der Einwurf mit Theoriefindung. Was ich schrieb ist keine Theorie, sondern Fakt. Überlege dir mal worum es in dem Artikel geht und beachte den Kontext des Artikels. Der Kontext ist nicht eine Befehlsarchitektur auf der identischen Befehlsarchitektur zum Laufen zu bringen, sondern, abgesehen von der nativen Ausführung, wie fremde Befehlsarchitketuren auf einer anderen Befehlsarchitekturen zum Laufen gebracht wird und das geht eben nur mit einem Emulator, weswegen das Wort "Virtuelle Maschine" falsch ist. --84.158.118.103 23:45, 25. Jan. 2025 (CET)
- Der Begriff " prozessbasierten virtuellen Maschinen" ist nur ein anderes Wort und ein schlechter und anderer Bezeichner für das Wort Emulator, was es letzten Endes ja ist. Und ob man auf einem Emulator ganze Betriebssysteme hostet oder nur einzelne Anwendungsprozesse, oder den Binärcode mithilfe eines JIT Compilers in nativen Binärcode übersetzt macht hier keinen Unterschied. --84.158.118.103 23:12, 24. Jan. 2025 (CET)
- Nachtrag: Die JavaVM implementiert ihren eigenen Befehlssatz, und hat damit eine Befehlssatzarchitektur, die man mit "Java Virtual Machine instruction set" bezeichnen könnte. Das tut zumindest dieses Assembler für Java: https://jasmin.sourceforge.net/. ‣Andreas•⚖ 22:33, 23. Jan. 2025 (CET)
- Wie schon gesagt wir der Bytecode vom JiT Compiler übersetzt. Dass der Bytecode aus Befehlen des Befehlssatz eines definierten und gedachten Prozessors für Java besteht, ändert daran ja nichts, dass er übersetzt und dann nativ mit nativen Befehlen der Ziel CPU ausgeführt wird. --84.158.118.103 23:09, 24. Jan. 2025 (CET)
- Darum geht es hier nicht. Man könnte einen Java-Prozessor in Hardware machen, dann wäre es keine VM mehr. Wo die Emulation anfängt, und was eine VM ist, bestimmen nicht wir hier, sondern es muss belegt werden. So ist es belegt, dass Microsoft bei der Entwicklung von Windows NT (das ja als Version 3.1 veröffentlicht wurde) einen Emulator des Intel i860 verwendet hatte. Belegt als Emulator. Es ist aber auch belegt, dass Java eine VM ist, und eben kein Emulator. ‣Andreas•⚖ 12:37, 25. Jan. 2025 (CET)
- Entschuldigt bitte, wenn ich mich hier einfach mal einmische. Also die Java-VM ist (aus meiner Sicht) letztlich (soweit erstmal, auch, ähnlich wie Qemu) nur eine Benennung (vom ursprünglichen Entwickler), wobei (auch die von mir hier nun rein zufällig) Erstgenannte (vom Orakel), bisher, einfach nur (mehr oder weniger unverändert) beibehalten wurde. Zudem denke ich aber auch, daß diese (im Übrigen, soweit ich das auch hier bisher sehe, nur aus dem Amerikanischen stammende) Unterscheidung (oder auch [viel zu scharfe] Trennung), von wegen Virtuelle Maschine vs. Emulator (zudem ggf. dauerhafter) oder auch von wegen Virtualisierung (wörtlich, eben zum amerikanischen vs.) gegen Emulation, schon von Anfang an müßig war, da beide Ansätze (also zum Einen hier wohl hauptsächlich aus Anwender-Sicht, wo es darum geht, Anwendungsumgebungen (sowie hauptsächlich, hier übrigens auch teilweise noch immer unübersetzt, auch sobezeichnete Desktop-Umgebungen), ggf. in mehreren Schichten, so abzubilden, daß bspw. ein virtueller Windows-Rechner auch auf einem Linux-Server läuft [und umgekehrt] oder, wenigstens eine Ebene [sowie Ausführungsschicht] tiefer [oder, aus umgekehrter Blickrichtung, höher], wo ebenfalls [beliebige] Anwendungen (sowie eben freiprogrammierbare Anwendungsprogramme), ursprünglich nur für ein Rechenwerk(-Stamm oder eine -Reihe sowie denglisch -Serie) beschrieben, auch auf anderen Rechenwerken laufen sollen und dazu dann eben entsprechend die jeweils zugrundeliegenden Befehlssätze nachgebildet werden) eigentlich schon lange überholt ist, auch weil beide Ansätze (also die anfängliche Emulation genauso wie die wohl jüngere Virtualisierung) in beiden Entwicklungsrichtungen (siehe ggf. Emulator und Virtualisierer), soweit ich das bisher (bspw. bei VBox sowie DBox und [mutmaßlich auch bei] Qemu) gesehen habe, (mal mehr und mal weniger häufig) verwendet werden, eben je nach dem, was (sowohl den Entwicklern als auch den Endanwendern) gerade wichtiger ist, also wenn es um Geschwindigkeit geht, wird wohl eher virtualisiert (also möglichst nur oberflächlich, mit möglichst wenig Overhead, und damit schnell, nachgebildet) und wenn es (bspw. aus Sicherheitsgründen oder, wie weiter vorgenannt, aus ebenso überholten, ja ewiggestrigen Urheberrechtsgründen) um möglichst vollständige (im Sinne von unveränderter Ausführungen geht) dann wird (eben) eher (vollständiger) emuliert oder eben (übersetzt, möglichste jeder einzelne Befehl, nach oben hin [zur Endanwendung, sowie auch umgekehrt, nach unten, zum Rechenwerk oder irgendeine Schicht dazwischen], bis hin zu jedem einzelnen Übergabewert, eben mal mehr und mal weniger genau) nachgebildet. Mit lieben Grüßen. -- 78.55.91.88 13:20, 25. Jan. 2025 (CET)
- Das alles ist im Nu erledigt, wenn sich jemand die Arbeit antun würde, ein (besser zwei, drei) Fachbuch (-bücher) über Virtualisierung/Emulation ausfindig zu machen, in dem (denen) das alles genau so erklärt wird, und das damit die JavaVM "debunkt" als Emulator. Die Bücher, die ich in der Zwischenzeit finden konnte, tun aber das Gegenteil.
- Betriebssysteme – Grundlagen und Konzepte, Rüdiger Brause, 2. überarbeitete Auflage, Springer-Verlag, 2001, ISBN 978-3-540-67598-3, Seite 3, Kapitel 1.3: Schnittstellen und virtuelle Maschinen; Zitat: ... Schichtenmodell ... Dienstleistungen ... Das Programm, das diese Dienstleistungen erbringt, kann nun selbst wieder als Befehlssequenz aufgefaßt werden, die darunter liegende, elementarere Dienstleistungen als eigene Leistungen benutzt. Die allerunterste Schicht, die die Arbeit nun tatsächlich auch ausführt, wird von der "darunterliegenden" Maschinenhardware gebildet. Da sich ihre Funktionen, so wie bei allen Schichten, über Schnittstellen ansteuern lassen, kann man die darüber liegende Einheit ebenfalls als eine Maschine auffassen. Allerdings erbringt sie die Arbeit nicht selbst; sie ist keine reale Maschine und wird deshalb als virtuelle Maschine bezeichnet.
- 52 Stunden Informatik – Was jeder über Informatik wissen sollte, Timm Eichstädt und Stefan Spieker, 2. Auflage, Springer Vieweg Fachmedien, 2021, ISBN 978-3-658-41837-3, Seite 220, Kapitel 26: Virtualisierung; Zitat: Die Virtualisierung ist eine Technik, die darauf abzielt, Ressourcen zu teilen und damit effizienter zu nutzen oder eine einheitliche Zwischenschicht zu bieten, um Unterschiede der Hardware zu abstrahieren, die noch über die Funktionalität des Betriebssystems hinausgehen.
Die häufigste Verwendung des Namens Virtual Machine (virtuelle Maschine) findet sich im Umfeld von Servervirtualisierung und bezeichnet hier ein abgeschottet laufendes virtualisiertes System. Auf einer solchen virtuellen Maschine können Anwendungen laufen, die über das Internet erreichbar sein sollen. Daneben werden virtuelle Laufzeitumgebungen für Programme, die speziell für diese Laufzeitumgebung geschrieben wurden, ebenfalls als virtuelle Maschinen bezeichnet. (Es folgt die JavaVM...)
Seite 223, selbes Kapitel; Zitat: Aber auch zu Hause kann Virtualisierung helfen, alte Spiele, für die die Spielkonsole kaputt ist, wiederzubeleben. So kennen viele, die heute selbst Kinder haben, noch den Super Nintendo. … Als Emulator (von lateinisch aemulari, nachahmen) wird ein System bezeichnet, das ein anderes nachbildet. Es ist eng verbunden mit der Virtualisierung, unterscheidet sich aber darin, dass nur ein Teil der Funktionen nachgebildet wird. Die Emulation versucht mittels Software, das Verhalten der Hardware nachzubilden. So kann die CPU-Last eines alten Spiels auch schon mal ungewöhnlich hoch sein.
- ‣Andreas•⚖ 15:24, 25. Jan. 2025 (CET)
- Das alles ist im Nu erledigt, wenn sich jemand die Arbeit antun würde, ein (besser zwei, drei) Fachbuch (-bücher) über Virtualisierung/Emulation ausfindig zu machen, in dem (denen) das alles genau so erklärt wird, und das damit die JavaVM "debunkt" als Emulator. Die Bücher, die ich in der Zwischenzeit finden konnte, tun aber das Gegenteil.
- Entschuldigt bitte, wenn ich mich hier einfach mal einmische. Also die Java-VM ist (aus meiner Sicht) letztlich (soweit erstmal, auch, ähnlich wie Qemu) nur eine Benennung (vom ursprünglichen Entwickler), wobei (auch die von mir hier nun rein zufällig) Erstgenannte (vom Orakel), bisher, einfach nur (mehr oder weniger unverändert) beibehalten wurde. Zudem denke ich aber auch, daß diese (im Übrigen, soweit ich das auch hier bisher sehe, nur aus dem Amerikanischen stammende) Unterscheidung (oder auch [viel zu scharfe] Trennung), von wegen Virtuelle Maschine vs. Emulator (zudem ggf. dauerhafter) oder auch von wegen Virtualisierung (wörtlich, eben zum amerikanischen vs.) gegen Emulation, schon von Anfang an müßig war, da beide Ansätze (also zum Einen hier wohl hauptsächlich aus Anwender-Sicht, wo es darum geht, Anwendungsumgebungen (sowie hauptsächlich, hier übrigens auch teilweise noch immer unübersetzt, auch sobezeichnete Desktop-Umgebungen), ggf. in mehreren Schichten, so abzubilden, daß bspw. ein virtueller Windows-Rechner auch auf einem Linux-Server läuft [und umgekehrt] oder, wenigstens eine Ebene [sowie Ausführungsschicht] tiefer [oder, aus umgekehrter Blickrichtung, höher], wo ebenfalls [beliebige] Anwendungen (sowie eben freiprogrammierbare Anwendungsprogramme), ursprünglich nur für ein Rechenwerk(-Stamm oder eine -Reihe sowie denglisch -Serie) beschrieben, auch auf anderen Rechenwerken laufen sollen und dazu dann eben entsprechend die jeweils zugrundeliegenden Befehlssätze nachgebildet werden) eigentlich schon lange überholt ist, auch weil beide Ansätze (also die anfängliche Emulation genauso wie die wohl jüngere Virtualisierung) in beiden Entwicklungsrichtungen (siehe ggf. Emulator und Virtualisierer), soweit ich das bisher (bspw. bei VBox sowie DBox und [mutmaßlich auch bei] Qemu) gesehen habe, (mal mehr und mal weniger häufig) verwendet werden, eben je nach dem, was (sowohl den Entwicklern als auch den Endanwendern) gerade wichtiger ist, also wenn es um Geschwindigkeit geht, wird wohl eher virtualisiert (also möglichst nur oberflächlich, mit möglichst wenig Overhead, und damit schnell, nachgebildet) und wenn es (bspw. aus Sicherheitsgründen oder, wie weiter vorgenannt, aus ebenso überholten, ja ewiggestrigen Urheberrechtsgründen) um möglichst vollständige (im Sinne von unveränderter Ausführungen geht) dann wird (eben) eher (vollständiger) emuliert oder eben (übersetzt, möglichste jeder einzelne Befehl, nach oben hin [zur Endanwendung, sowie auch umgekehrt, nach unten, zum Rechenwerk oder irgendeine Schicht dazwischen], bis hin zu jedem einzelnen Übergabewert, eben mal mehr und mal weniger genau) nachgebildet. Mit lieben Grüßen. -- 78.55.91.88 13:20, 25. Jan. 2025 (CET)
- Darum geht es hier nicht. Man könnte einen Java-Prozessor in Hardware machen, dann wäre es keine VM mehr. Wo die Emulation anfängt, und was eine VM ist, bestimmen nicht wir hier, sondern es muss belegt werden. So ist es belegt, dass Microsoft bei der Entwicklung von Windows NT (das ja als Version 3.1 veröffentlicht wurde) einen Emulator des Intel i860 verwendet hatte. Belegt als Emulator. Es ist aber auch belegt, dass Java eine VM ist, und eben kein Emulator. ‣Andreas•⚖ 12:37, 25. Jan. 2025 (CET)
- Wie schon gesagt wir der Bytecode vom JiT Compiler übersetzt. Dass der Bytecode aus Befehlen des Befehlssatz eines definierten und gedachten Prozessors für Java besteht, ändert daran ja nichts, dass er übersetzt und dann nativ mit nativen Befehlen der Ziel CPU ausgeführt wird. --84.158.118.103 23:09, 24. Jan. 2025 (CET)
- Nun ja, "prozessbasierte virtuelle Maschinen" sind aber im Artikel Virtuelle Maschine #Typen virtueller Maschinen belegt. ‣Andreas•⚖ 22:00, 23. Jan. 2025 (CET)
- Das sind Kleinigkeitendetails, um die geht es hier aber nicht. Mir geht es hier um fremde Architektur = Emulation erforderlich und dass diese Emulation keine Virtuelle Maschine ist. --84.158.118.103 03:30, 23. Jan. 2025 (CET)
- Huh, da ist sie wieder, die (mir) viel zu scharfe Unterscheidung zwischen VM und Emulator. Naja, ist nicht mein Bier, du Andreas bestehst (nun ja offenbar weiterhin) auf diese (mir viel zu scharfe) Unterscheidung, dann ist das eben auch deine Angelegenheit, im Übrigen, hier (auf der Vorderseite, gegenwärtig noch immer angeführt mit und ebenso), zur Befehlssatzarchitektur, eigentlich falsch, da es dafür ja auch hier, noch immer die zwei (oben schon genannten Haupt-)Einträge eben zur virtuellen Maschine und zum Emulator eben mit zugehörigen Besprechungsseiten (ebenso noch immer denglisch verschwurbelt unter Diskussion:Virtuelle Maschine und Diskussion:Emulator) gibt. Desweiteren ist das erste von dir genannte Buch aus dem Jahre 2001, also (aus meiner Sicht, nun, im Jahre 2025) auch schon (wenigstens teilweise) veraltet. Und dann von wegen „debunkt“ (dem Google-Übersetzer nach ist das Niederländisch, hier also, ähnlich wie dieser ganze Ammi-Kram, stenggenommen, auch falsch, und heißt hier) also (nach dessen Übersetzung, mir eigentlich zu reißerisch) „entlarvt“, naja, zielt also wieder nur auf die (mir, ganz besonders hier viel zu) strenge Unterscheidung ab, welche hier (also, kürzer übersetzt, einfach durch Weglassung des hier noch immer anhaftenden Fremd-Geschwurbels, zu den Befehlssätzen) eben auch schlicht die falsche (Wander?-)Baustelle ist. Also eigentlich sollte, hier in der Wikipedia, in jedem (üblichen Haupt-)Eintrag, je ein Begriff (zudem hier vorzugsweise in deutscher Sprache) beschrieben werden. Naja, zuviel dann auch mal zu Wunsch und Wirklichkeit. Und da ich schonmal dabei bin, so jedenfalls wenigstens meiner Ansicht nach, gehört dieses „debunkt“ und ebenso das wohl zugehörige Debunking, besser ins (Fremdwort-)Wörterbuch. -- 78.55.91.88 16:53, 25. Jan. 2025 (CET)
- Andere Baustelle. Welche Wörter im deutschen Sprachraum üblich sind und welche nicht, liegt nicht an uns hier selbst festzulegen, oder gar eine vermeintlich richtige (weil deutsche) der Allgemeinheit aufs Aug zu drücken.
- Das Buch aus 2001 (1. Auflage: 1998) habe ich deswegen hinzugefügt, weil es die VM am schönsten beschreibt. Das Buch aus 2021 ist jedoch nur eines von mehreren, die aktuell sind und die JavaVM als eine VM bezeichnen. Nochmals: den Begriff Emulator (oder Emulation) findet man bei Java nicht. ‣Andreas•⚖ 17:26, 25. Jan. 2025 (CET)
- Huh, da ist sie wieder, die (mir) viel zu scharfe Unterscheidung zwischen VM und Emulator. Naja, ist nicht mein Bier, du Andreas bestehst (nun ja offenbar weiterhin) auf diese (mir viel zu scharfe) Unterscheidung, dann ist das eben auch deine Angelegenheit, im Übrigen, hier (auf der Vorderseite, gegenwärtig noch immer angeführt mit und ebenso), zur Befehlssatzarchitektur, eigentlich falsch, da es dafür ja auch hier, noch immer die zwei (oben schon genannten Haupt-)Einträge eben zur virtuellen Maschine und zum Emulator eben mit zugehörigen Besprechungsseiten (ebenso noch immer denglisch verschwurbelt unter Diskussion:Virtuelle Maschine und Diskussion:Emulator) gibt. Desweiteren ist das erste von dir genannte Buch aus dem Jahre 2001, also (aus meiner Sicht, nun, im Jahre 2025) auch schon (wenigstens teilweise) veraltet. Und dann von wegen „debunkt“ (dem Google-Übersetzer nach ist das Niederländisch, hier also, ähnlich wie dieser ganze Ammi-Kram, stenggenommen, auch falsch, und heißt hier) also (nach dessen Übersetzung, mir eigentlich zu reißerisch) „entlarvt“, naja, zielt also wieder nur auf die (mir, ganz besonders hier viel zu) strenge Unterscheidung ab, welche hier (also, kürzer übersetzt, einfach durch Weglassung des hier noch immer anhaftenden Fremd-Geschwurbels, zu den Befehlssätzen) eben auch schlicht die falsche (Wander?-)Baustelle ist. Also eigentlich sollte, hier in der Wikipedia, in jedem (üblichen Haupt-)Eintrag, je ein Begriff (zudem hier vorzugsweise in deutscher Sprache) beschrieben werden. Naja, zuviel dann auch mal zu Wunsch und Wirklichkeit. Und da ich schonmal dabei bin, so jedenfalls wenigstens meiner Ansicht nach, gehört dieses „debunkt“ und ebenso das wohl zugehörige Debunking, besser ins (Fremdwort-)Wörterbuch. -- 78.55.91.88 16:53, 25. Jan. 2025 (CET)
- Den Teil zur deutschen Sprache kannst du ja so sehen, ich finde dieses Geschwurbel (meinem Gefühl nach, immer weiter in Richtung denglisch, mit dem [End]Ziel Englisch), hier, in der vorgeblich deutschsprachigen Wikipedia, einfach nur daneben.
- Und was die (aus deiner Sicht) anderen beiden Begriffe (letztlich, meiner Ansicht nach, den selben Begriff) angeht, nochmal, das gehört (im besten Fall einfach nur so ausführlich) einfach nicht hierher, zur Befehlssatzarchitektur (siehe oben genannte Besprechungsseiten). -- 78.55.91.88 17:34, 25. Jan. 2025 (CET)
- Zur deutschen Sprache: auf den Diskussionsseiten kann jeder so schreiben, wie er will. Wenn er so schreibt, dass ihn keiner versteht, ist das sein Problem. Das ist aber Sprach-unabhängig. Im Bereich der Computer ist eben vielfach Englisch eingewoben. Es gibt aber auch das Amtsdeutsch, und das versteht auch nicht jeder. Und dann gibt es noch viele, viele andere Bereiche, in denen sich eigene Sprachgewohnheiten gebildet haben. Mediziner sprechen ja auch anders als einfache Angestellte, und auch Wissenschaftler brauchen immer wieder Übersetzer, weshalb es Wissenschaftsjournalisten bedarf. (Allein das Beispiel "Theorie", ein Begriff, der im Volksmund ganz was anderes bedeutet als in der Wissenschaft...)
- Zum Ort der Diskussion: der OP hat auf den Abschnitt #Virtuelle Maschine direkt Bezug genommen. Ja, die Diskussion ist etwas aus dem Ruder gelaufen, aber prinzipiell ging es um das, was in diesem Artikel steht. ‣Andreas•⚖ 17:59, 25. Jan. 2025 (CET)
- Das ist meiner Ansicht nach nur eine (aus meiner Sicht auch immer wieder und schon viel zu oft vorgebrachte, letztlich aber nur faule) Ausrede, also wenn Andere (bspw. hier zudem fachfremd, im vorgeblich Amtsdeutschen und ebenso im Medizin-Sprech oder, hier wenigsten fachbezogen, in der IT, sprich, [nur vorgeblich einge]deutsch[t] Ih-Teh, englisch Aitih) rumschwurbeln, dann
müssen wirmußt du das hier also auch so (dämlich/schwachsinnig mit-/)nachmachen, ja? Naja, du kann das ja von mir aus halten wie du willst, Denglisch ist und bleibt einfach nur dumm und ist hier, meiner Ansicht nach, auch grundfalsch, gleichgültig was du dazu nun noch so vor- und (deiner Ansicht nach) entgegenzubringen glaubst. Letztlich ist es mit der Sprache wie bei Kindern, wenn man den Menschen sowie unwissenden Kindern immer alles durchgehen läßt, also niemand sie erzieht, dann kommt am Ende (meistens) nur noch irgendein (ist jetzt auch nichts gegen dich persönlich, uner- oder, ähnlich wie ein ungepflegter Garten, eben ungezogener-)Müll (oder, um im vorgenannten Bild zu bleiben, irgendein entsprechend unansehnliches Gestrüpp) dabei raus (wo dann auch wieder nur noch die stärksten invasiven Arten überleben). Andererseits, ist es mir nun auch schon wieder viel zu anstrengend, auch dich noch weiter auf die Pflege der hier zu verwendenden Sprache hinzuweisen (und damit auch schon erzieherische Maßnahmen zu tätigen). Mach doch was du willst. Ich schau dann eh einfach woanders hin, bis hier in der vorgeblich deutschsprachigen Wikipedia dieser ganze (äußerst unansehnlich) Denglisch-Müll (bestenfalls) nur äußerst zähe oder (treffender) sehr sehr langwierig (irgendwann) mal weggeräumt wird. Zudem ist die (deutschsprachige) Wikipedia (so jedenfalls für mich) ziemlich nutzlos, solange auch hier dieses (Denglisch-)Geschwurbel (bspw. von Heise und anderen Aitihlern) einfach nur (ohne mal darüber nachzudenken) wiedergekäut (und dabei eben nicht anständig [weiter] übersetzt) wird. -- 78.55.91.88 18:43, 25. Jan. 2025 (CET)- Deine Ansicht ist mir vollkommen egal. Auch meine Ansicht ist nur eine Ansicht. Mein "Sprech" ist irrelevant. Wenn dich der so sehr stört, dann geh doch einfach.
- Wichtig ist nur der Artikel. Dort schreibe ich natürlich nicht "debunkt". Das passt nicht. Der Artikel soll korrekt sein, und da muss etwas, was man behauptet, belegt sein. Dass du das immer noch nicht verstehen willst, ist dein Problem, und deines alleine.
- Geh bitte mit deinen erzieherischen Maßnahmen wo anders hin. ‣Andreas•⚖ 22:52, 25. Jan. 2025 (CET)
- Nachtrag: Apropos "Denglisch": die von mir eingebrachten Belege in dieser Diskussion sind aus Fachbüchern. Nix Heise, obwohl es natürlich die Aufgabe einer Enzyklopädie ist, die Begriffe, die sich in der Welt so finden, zu erklären, und nicht eine Parallelwelt zu entwickeln, wie die Begriffe (nach wessen Meinung?) korrekt wären. Wer das nicht verstanden hat, muss sich wohl nochmals die Wikipedia-Regeln durchlesen. ‣Andreas•⚖ 22:55, 25. Jan. 2025 (CET)
- Das ist meiner Ansicht nach nur eine (aus meiner Sicht auch immer wieder und schon viel zu oft vorgebrachte, letztlich aber nur faule) Ausrede, also wenn Andere (bspw. hier zudem fachfremd, im vorgeblich Amtsdeutschen und ebenso im Medizin-Sprech oder, hier wenigsten fachbezogen, in der IT, sprich, [nur vorgeblich einge]deutsch[t] Ih-Teh, englisch Aitih) rumschwurbeln, dann
- Nachtrag: Software wie SheepShaver oder Mac-on-Linux mach(t)en dasselbe auf der PowerPC-Architektur, denn diese hatte damals ebenfalls keine Hardware-Virtualisierungsfunktionen. Andere Programme wie PearPC oder Basilisk II hingegen emulieren eine andere Prozessorarchitektur als jene, auf der sie laufen. (PearPC: für PowerPC-Mac-OS-X auf x86-Hardware, Basilisk II: für 68k-Mac-OS auf PowerPC-Hardware.) ‣Andreas•⚖ 16:00, 22. Jan. 2025 (CET)