VirtualBox,Qemu und Java Virtual Machine um nur drei Beispiele zu nennen. VirtualBox beherrscht echte Virtualisierung. Qemu ist dagegen ein Emulator und die Java Virtual Machine (als Beispiel für derartige virtuelle Maschinen) ist keine virtuelle Maschine im Sinne der Virtualisierung wie bei VirtualBox sondern einer im Sinne einer abstrakten Maschine. Eigentlich emuliert die JVM eine abstrakte Maschine. In Wikipedia ist noch beschrieben die Unterscheidung zwischen einer Systembasierten Virtualisierung wie es bei VirtualBox oder VMwares zutrifft und einer prozessbasierten Virtualisierung wie es bei Laufzeitumgebungen wie .Net oder Java-Plattform der Fall sei. Sind diese Bemühungen einer präzisen Definition überhaupt sinnvoll? Oder fasst das jeder so auf wie er will? Ich könnte also ein Programm schreiben das Hardware simuliert und sich mit einem eigenen Assembler programmieren lässt und das ganze wäre dann was? Eine virtuelle Maschine? Nicht wie bei VirtualBox aber so wie bei JVM? Oder wäre das ein Emulator? Wäre es systembasiert oder prozessbasiert? Hilfe! :D
Defino schrieb: > Wäre es systembasiert oder prozessbasiert? Um bei deiner Definition zu bleiben: weder noch, da es keine Virtualisierung ist sondern eine Emulation;)
knoxX schrieb: > JVM ist ein bytecode-Interpreter Inerpretiert aber nicht für das System auf dem er läuft, sondern für eine abstrakte Maschine, die auf der echten Maschine ausgeführt wird. https://m.youtube.com/watch?v=WniOZT7FlKM
Eigentlich nicht da schrieb: > Inerpretiert aber nicht für das System auf dem er läuft, sondern für > eine abstrakte Maschine, die auf der echten Maschine ausgeführt wird. Was soll das nun wieder bedeuten*Zeigefingerlutschsmiley*
knoxX schrieb: > JVM ist ein bytecode-Interpreter Ein Bytecode-Interpreter ist eine mögliche Implementierung der JVM, aber nicht die einzig mögliche. Just-in-time-Kompilierung ist eine andere, ebenso wie zwischenzeitlich ARMs Jazelle den Bytecode direkt ausführte.
KknoxX schrieb: > Eigentlich nicht da schrieb: > Inerpretiert aber nicht für das System auf dem er läuft, sondern für > eine abstrakte Maschine, die auf der echten Maschine ausgeführt wird. > > Was soll das nun wieder bedeuten*Zeigefingerlutschsmiley* Das musst du das Oralcle fragen welches auch der Architkt dieser VM ist.
Eigentlich nicht da schrieb: > KknoxX schrieb: >> Eigentlich nicht da schrieb: >> Inerpretiert aber nicht für das System auf dem er läuft, sondern für >> eine abstrakte Maschine, die auf der echten Maschine ausgeführt wird. >> >> Was soll das nun wieder bedeuten*Zeigefingerlutschsmiley* > > Das musst du das Oralcle fragen welches auch der Architkt dieser VM ist. Virtualbox wurde in der Nähe von Stuttgart entwickelt. Der jetzige Besitzer hat es als Beifang des Sun-Kaufs bekommen.
Defino schrieb: > VirtualBox beherrscht echte Virtualisierung. VirtualBox kann aber auch emulieren. Muss es für fast alle Peripherie auch (CPU ausgenommen). > Qemu ist dagegen ein Emulator Qemu kann aber auch Virtualisierung. Und TCG ist auch keine echte Emulation, sondern ein JIT-Compiler. > und die Java Virtual Machine (als Beispiel für derartige > virtuelle Maschinen) ist keine virtuelle Maschine Klar ist es eine virtuelle Maschine. Nur, dass es diese Maschine nicht in "real" gibt.
:
Bearbeitet durch User
S. R. schrieb: > Klar ist es eine virtuelle Maschine. > Nur, dass es diese Maschine nicht in "real" gibt. Das ist aber kein Naturgesetz. Für den Pascal-Bytecode gab es mal einen Chipsatz, der das direkt ausgeführt hat (Pascal Microengine). Ich hatte so eine Maschine, die war verglichen mit Interpretern und für die damalige Zeit rasend schnell. Ob es Hardware anstelle der JVM gibt weiss ich nicht, aber möglich wäre das natürlich, ist auch nicht schwieriger als irgendein anderer Prozessor. Fragt sich nur ob sich das lohnt. Georg
georg schrieb: > Ob es Hardware anstelle der JVM gibt weiss ich nicht, aber möglich wäre > das natürlich, ist auch nicht schwieriger als irgendein anderer > Prozessor. Fragt sich nur ob sich das lohnt. Lohnt nicht, JIT ist zwar aufwändiger, aber schneller. ARM hatte das mit Jazelle in älteren ARMs und Sun hatte in Verilog einen picoJava Prozessor definiert. Bei AVR32 gibts das anscheinend noch(?). Allerdings ist eine Stack-Maschine auf halbwegs modernen Prozessorstrukturen notorisch ineffizient. Ein optimierender JIT Compiler kriegt das besser hin, weshalb solche Ansätze schon vor längerer Zeit wieder verschwanden.
:
Bearbeitet durch User
S. R. schrieb: > Klar ist es eine virtuelle Maschine. > Nur, dass es diese Maschine nicht in "real" gibt. The JVM is not a virtual machine in that sense at all. No hardware other than the processor is virtualized. The JVM is essentially a virtualized CPU plus the same sort of runtime that is included with a C++ or any other object oriented language, plus garbage collection and other necessities. Additionally, of course, Java class files (and JAR files, etc) are not machine code, but an intermediate byte code. So the JVM has to compile or interpret class files (whether contained in a JAR file or not) at runtime, and has the ability to load and find new code dynamically at runtime. The JVM is called a virtual machine because the JVM definition defines an abstract machine. This includes registers, stack, etc, and the byte code that Java source is compiled to is practically machine code for this virtual machine. The JVM then interprets or compiles this byte code into native machine instructions. The difference is essentially that the JVM is a virtualized processor and the other virtual machines are virtualized machines (including video card, network, and other external devices and hardware registers). Quelle: https://stackoverflow.com/questions/861422/is-the-java-virtual-machine-really-a-virtual-machine-in-the-same-sense-as-my-vmw
Ich hätte da noch die "abstract virtual machine" der C Standards.
Interreso schrieb: > The JVM is not a virtual machine in that sense at all. > No hardware other than the processor is virtualized. Vielen Dank für ihre Antwort. Leider beantworteten Sie die falsche Frage.
A. K. schrieb: > Ich hätte da noch die "abstract virtual machine" der C Standards. Das ist nur eine "abstract machine", ohne "virtual". "Abstract" ist hier in dem Sinne gemeint, dass die Maschine nur über bestimmte Verhaltensmuster als Prosa-Text beschrieben ist. Es gibt keinen Maschinencode oder Bytecode. S. R. schrieb: > Vielen Dank für ihre Antwort. > Leider beantworteten Sie die falsche Frage. Es widerspricht deiner Aussage. Wenn es die falsche Frage beantwortet, dann hast du das wohl auch getan.
Defino schrieb: > VirtualBox beherrscht echte Virtualisierung. Qemu ist dagegen ein > Emulator QEMU ist mit KVM genaugenommen ein Hybrid, da Qemu sowohl emulieren, als auch mit KVM virtualisieren kann. Ein reiner Emulator wäre aber Bochs. > In Wikipedia ist noch beschrieben die Unterscheidung zwischen einer > Systembasierten Virtualisierung wie es bei VirtualBox oder VMwares > zutrifft und einer prozessbasierten Virtualisierung wie es bei > Laufzeitumgebungen wie .Net oder Java-Plattform der Fall sei. > > Sind diese Bemühungen einer präzisen Definition überhaupt sinnvoll? Oder > fasst das jeder so auf wie er will? Warum sollen Sie nicht sinnvoll sein? Bei der JVM werden in der Regel nur einzelne Prozesse ausgeführt. > Ich könnte also ein Programm schreiben das Hardware simuliert und sich > mit einem eigenen Assembler programmieren lässt und das ganze wäre dann > was? Es wäre ein Emulator. Für eine VM muss die simulierte Hardware die gleiche Architektur wie das Hostsystem haben. Bei der Simulation wird man bei einer VM dann die echte Hardware zur Ausführung nutzen, die VM muss somit die Haradware nicht vollständig nachgebilden, sondern diese nur entsprechend vor dem auszuführenden Gastsystem abstrahieren.
Nano schrieb: > Für eine VM muss die simulierte Hardware die gleiche Architektur wie das > Hostsystem haben. Der Unterschied zur binary translation zur Laufzeit erscheint mir fliessend. In der Frühzeit übersetzte VMware den damals eigentlich nicht virtualisierbaren 32-Bit x86-Code zu harmlosem x86-Code, was die Sache deutlich erleichert. Die Übersetzung von ARM-Code in x86-Code ist zwar weniger effizient, aber nicht fundamental verschieden.
:
Bearbeitet durch User
Rolf M. schrieb: >> Vielen Dank für ihre Antwort. >> Leider beantworteten Sie die falsche Frage. > Es widerspricht deiner Aussage. Wenn es die falsche > Frage beantwortet, dann hast du das wohl auch getan. Ich sprach von "Ist die JVM eine virtuelle Maschine?". Die Antwort ist "ja". Das Zitat sprach von "Ist die JVM eine virtuelle Maschine, genauso wie VMware oder Parallels?". Die Antwort ist "nein", denn letztere emulieren(!) zusätzliche Hardware, was die JVM nicht tut. Unterschiedliche Fragen, unterschiedliche Antworten. Nano schrieb: > Für eine VM muss die simulierte Hardware die > gleiche Architektur wie das Hostsystem haben. Das stimmt nicht: Der 80386 ist IA-32, die damit erzeugten virtuellen Maschinen (VM86) sind aber IA-16. Der V20 ist zwar IA-16, aber die damit erzeugten virtuellen Maschinen sind i8080. Und von den ganzen Mainframes, bei denen die gleiche Argumentation auch zählt, möchte ich garnicht reden.
S. R. schrieb: > Nano schrieb: >> Für eine VM muss die simulierte Hardware die >> gleiche Architektur wie das Hostsystem haben. > > Das stimmt nicht: Der 80386 ist IA-32, die damit erzeugten virtuellen > Maschinen (VM86) sind aber IA-16. Das ist Teil der Abwärtskompatibilität. Das ist also eins und etwas völlig anderes, als wenn du x86 Hardware auf einem 68k Prozessoer virtualisieren willst. Letzteres geht nämlich nicht, weil die Architekturen zu unterscheidlich sind, da geht dann nur noch die Emulation aber eben keine Virtualisierung. Kurz IA-32, x86-64 und IA-16 sind alle drei x86.
Nano schrieb: >> Der 80386 ist IA-32, die damit erzeugten virtuellen >> Maschinen (VM86) sind aber IA-16. > Das ist Teil der Abwärtskompatibilität. Ähm... nein. Innerhalb einer solchen VM kann ich nicht die gleichen Befehle ausführen wie außerhalb und die gesamte Ausführungsumgebung ist eine völlig andere. Der Punkt ist, dass die Architektur von 8086 und 80386 sehr unterschiedlich sind, die Virtualisierung des 80386 aber eher dem 8086 (+ Erweiterungen) entspricht. Deswegen ist es trotzdem Virtualisierung und trotzdem nicht die gleiche Architektur. Nano schrieb: > Kurz IA-32, x86-64 und IA-16 sind alle drei x86. Thumb, Thumb2, ARM32 und ARM64 sind verschiedene Befehlssätze, obwohl ein ARM-Prozessor wahrscheinlich mindestens zwei davon ausführen kann. Ebenso sind IA-16, IA-32 und x86-64 verschiedene Befehlssätze. Und sie sind auch nicht zueinander kompatibel: Ein x86-64-Prozessor kann kein IA-16 ausführen, solange er nicht in einem Kompatiblitätsmodus ist (in dem er dann auch kein x86-64 mehr kann).
S. R. schrieb: > Ebenso sind IA-16, IA-32 und x86-64 verschiedene Befehlssätze. Die Register, wie bspw. EAX ist aber nur einer Erweiterung von AX. Und EAX wurde für 64 Bit nur zu RAX erweitert, sowie zusätzliche neue Register hinzugefügt. Ebenso gibt's im 32 Bit Modus so gut wie alle Befehle oder Abwandlungen davon des 16 Bit Modus. Unterschiede sind im wesentlichen bezüglich Real Mode vs. Protected Mode zu beachten. > Und sie sind auch nicht zueinander kompatibel: Ein x86-64-Prozessor kann > kein IA-16 ausführen, solange er nicht in einem Kompatiblitätsmodus ist > (in dem er dann auch kein x86-64 mehr kann). Ja, das ist eine Ausnahme, da hat man im x86-64 Bit Modus die Abwärtskompatibilität aufgegeben. Was ja auch kein Wunder ist, wenn man den Unterschied der Speicherverwaltung zwischen 16 Bit und alles nach dem 386er vergleicht. Da war der 16 Bit Modus einfach eine Altlast.
Nano schrieb: >> Ebenso sind IA-16, IA-32 und x86-64 verschiedene Befehlssätze. > Die Register, wie bspw. EAX ist aber nur einer Erweiterung von AX. Das ist richtig, aber die gleiche Argumentation gilt für Thumb vs ARM auch, und dort spricht man von verschiedenen Befehlssätzen. > Ebenso gibt's im 32 Bit Modus so gut wie alle Befehle > oder Abwandlungen davon des 16 Bit Modus. Die gleichen Bytes liefern im im 16 Bit-Modus und im 32 Bit-Modus unterschiedliche Ergebnisse (im 32 Bit-Modus braucht man für 16 Bit-Befehle ein Address Override Prefix). Die gleiche Argumentation gilt für RV32 vs RV64 auch, und auch dort spricht man von unterschiedlichen Befehlssätzen. > Unterschiede sind im wesentlichen bezüglich > Real Mode vs. Protected Mode zu beachten. Das ist ein wesentlicher Unterschied in der Ausführungsumgebung. Die zählt ebenfalls zur "Instruction Set Architecture", ebenso wie die zusätzlichen Register (FS/GS) und die zusätzlichen Bits. Und zu guter Letzt: Nichtmal Intel behauptet, dass IA-16, IA-32 und x86_64 die gleichen Befehlssätze wären. Letzterer ist (im Gegensatz zu den anderen) ja nichtmal von Intel entwickelt worden. Die gleiche Argumentation gilt übrigens auch für i8080 vs Z80, und auch dort spricht man von verschiedenen Befehlssätzen. IA-16 und IA-32 sind verschiedene Befehlssätze. Ein 80386 unterstützt Hardwarevirtualisierung, aber die damit erstellten virtuellen Maschinen nutzen einen anderen Befehlssatz (VM86, ein erweitertes IA-16) als der 80386 selbst. Daraus folgt, dass Virtualisierung nicht zwingend erfordert, dass Host- und Gast-Architekturen identisch sind. Und ich riss bereits an, dass aktuelle z/OS-Systeme nach wie vor in der Lage sind, S/370-Programme (und sogar S/360) auszuführen. Die Fähigkeiten dafür erstrecken sich über sämtliche Ebenen der Architektur.
> denn letztere > emulieren(!) zusätzliche Hardware, was die JVM nicht tut. Wie sind denn da z.B. Libraries einzuordnen die z.B. den Zugriff auf serielle Schnittstellen durch die JVM erlauben?
Larry schrieb: > Wie sind denn da z.B. Libraries einzuordnen die z.B. > den Zugriff auf serielle Schnittstellen durch die JVM erlauben? Die simulieren keine serielle Schnittstelle, sondern geben dir Zugriff auf entsprechende APIs des Host-Betriebssystems.
S. R. schrieb: > Nano schrieb: >>> Ebenso sind IA-16, IA-32 und x86-64 verschiedene Befehlssätze. >> Die Register, wie bspw. EAX ist aber nur einer Erweiterung von AX. > > Das ist richtig, aber die gleiche Argumentation gilt für Thumb vs ARM > auch, und dort spricht man von verschiedenen Befehlssätzen. Aber nicht von einer anderen Architektur. Der Prozessor ist ja immer noch der selbe und kann den Code nativ ausführen. Und darum ging es ja: S. R. schrieb: > Nano schrieb: >> Für eine VM muss die simulierte Hardware die gleiche Architektur wie das >> Hostsystem haben. > > Das stimmt nicht: Der 80386 ist IA-32, die damit erzeugten virtuellen > Maschinen (VM86) sind aber IA-16. Der V20 ist zwar IA-16, aber die damit > erzeugten virtuellen Maschinen sind i8080.
:
Bearbeitet durch User
S. R. schrieb: > Letzterer ist (im Gegensatz zu > den anderen) ja nichtmal von Intel entwickelt worden. (sehr schönes Argument) -> man kann in diesem Zusammenhang zumindest fragen, was eigentlich mit einem kompatiblen Prozessor gemeint ist bzw. ab wann die Fahne "grün" vs ("rot", "gelb") oben ist ;) In der Praxis steht (stand) öfter die Frage im Hintergrund, ab wann die Maschine mit (veraltendem) Dos-Kompi als Bedienung wieder einsetzbar ist. Die Maschine weiß eventuell gar nicht, dass sie neuerdings von einer Linuxkiste bzw. einer freien Software-Bewegung aus gesteuert wird.
Rolf M. schrieb: > Aber nicht von einer anderen Architektur. Der Prozessor ist > ja immer noch der selbe und kann den Code nativ ausführen. Najaaaa.... ein Cortex-M3 kann weder Thumb noch ARM32 ausführen. Ein ARM7 weder Thumb2 noch ARM64. Und so weiter. Der Befehlssatz ist ein wesentlicher Bestandteil der Architektur. Und auch das entkräftet das Mainframe-Argument nicht.
Ich bin immer noch unsicher was mein Projekt eigentlich ist :D Ich bin dabei mit Python ein Programm/Simulator zu schreiben das eine "Maschine" simuliert. Die Maschine existiert in real bisher nicht sondern ist ursprünglich ein Entwurf aus integrierten Schaltkreisen. Es ist quasi ein Chip Entwurf. Mit einer neuen Architektur. Auf dem realen Chip könnten Programme ablaufen. Mein Simulator wird nicht die integrierten Schaltkreise simulieren sondern die funktionellen Eigenschaften der Chip Architektur. In meinem Simulator laufen die Programme also prinzipiell genau so ab wie auf dem möglichen realen Chip. Die Programme für meinen Simulator werden in einer einfachen Hochsprache geschrieben. Im Simulator bzw. durch weitere Komponenten wird der Quelltext geparst und in eine Assemblersprache für die "Maschine" umgewandelt. Diese Assemblersprache wird dann vom Simulator also der "Maschine" ausgeführt. Ist das ganze also ein Emulator? Wobei jemand auch mal meinte ein Emulator sei die Simulation von realer Hardware. Meine "Maschine" gibt es aber nicht wirklich. Man könnte es aber problemlos herstellen. Trotzdem ein Emulator?
Defino schrieb: > Ist das ganze also ein Emulator? Ja. > Wobei jemand auch mal meinte ein Emulator sei die Simulation von realer > Hardware. Ein Emulator kann direkt den nativen Code der emulierten Plattform ausführen. Wie er das macht, ist dafür zweitrangig. Er muss dazu nicht das Verhalten jedes Transistors einzeln nachbilden. Er muss aber auch das Verhalten der Peripherie irgendwie abbilden. > Meine "Maschine" gibt es aber nicht wirklich. Man könnte es aber > problemlos herstellen. Trotzdem ein Emulator? Ja, würde ich sagen.
Defino schrieb: > Meine "Maschine" gibt es aber nicht wirklich. Man könnte es aber > problemlos herstellen. Trotzdem ein Emulator? Hardwareentwicklung funktioniert heutzutage so, dass man die Beschreibung der Funktion in VHDL oder Verilog eingibt, und dann simuliert man das in einem Simulator. Und wenn man das in der Realität testen will, dann kippt man das in einen FPGA oder gießt es für teuer Geld in Silizium. Oder schmeißt es weg, wenn es nichts taugt. Wobei mir der Unterschied zwischen Simulator und Emulator nicht ganz klar ist. Scheint heutzutage das gleiche zu sein.
S. R. schrieb: > Wobei mir der Unterschied zwischen Simulator und Emulator nicht ganz > klar ist. Scheint heutzutage das gleiche zu sein. Das ist eher der Verwendungszweck, Simulator nimmt man zur Entwicklung, Emulator ist für Dauereinsatz - das heisst, im Simulator wird dauernd was geändert, bis die Sache läuft, an einem Emulator ändert sich normalerweise nichts. Aber technisch kann das ohne weiteres identisch sein, es ist sogar ein Vorteil wenn der Simulator exakt das gleiche macht wie ein später verwendeter Emulator. Georg
georg schrieb: > Das ist eher der Verwendungszweck, Simulator nimmt man zur Entwicklung, > Emulator ist für Dauereinsatz - das heisst, im Simulator wird dauernd > was geändert, bis die Sache läuft, an einem Emulator ändert sich > normalerweise nichts. Hm interessant. Also meine Software soll eigentlich beide Verwendungszwecke erfüllen. Es soll ein Simulator sein um die funktionellen Eigenschaften der möglichen realen Architektur zu testen: die möglichen Programme und deren Grenzen usw. Und es soll auch ein Emulator sein um die speziellen Eigenschaften der simulierten Architektur auf herkömmlichen Computern dauerhaft und unverändert nutzen zu können. S. R. schrieb: > Hardwareentwicklung funktioniert heutzutage so, dass man die > Beschreibung der Funktion in VHDL oder Verilog eingibt, und dann > simuliert man das in einem Simulator. Ich habe mich für eine Emulation (sofern diese Definition denn endlich mal wirklich zutrifft) entschieden weil das für mich gegenwärtig bedeutend einfacher ist. Die Kernfunktionalität der Architektur braucht knapp 150 Zeilen in Python. Bei VHDL stecke ich noch in den Grundlagen und habe keine Erfahrung damit. Wobei ich mir auch MyHDL noch näher anschauen möchte. Da MyHDL auf Python basiert soll dadurch das testen einfacher sein.
Ist die Bezeichnung virtual machine in diesem Zusammenhang hier nicht falsch? https://justinmeiners.github.io/lc3-vm/ Dort wird keine Virtualisierungstechnik wie in VirtualBox genutzt. Sondern nur die LC-3 Architektur simuliert. Trotzdem spricht der Autor von einer virtual machine. https://en.wikipedia.org/wiki/Little_Computer_3
Hier mal was historisches: The word "emulator" was coined in 1963 at IBM[19] during development of the NPL (IBM System/360) product line, using a "new combination of software, microcode, and hardware".[20] They discovered that simulation using additional instructions implemented in microcode and hardware, instead of software simulation using only standard instructions, to execute programs written for earlier IBM computers dramatically increased simulation speed. Earlier, IBM provided simulators for, e.g., the 650 on the 705.[21] In addition to simulators, IBM had compatibility features on the 709 and 7090,[22] for which it provided the IBM 709 computer with a program to run legacy programs written for the IBM 704 on the 709 and later on the IBM 7090. This program used the instructions added by the compatibility feature[23] to trap instructions requiring special handling; all other 704 instructions ran the same on a 7090. The compatibility feature on the 1410[24] only required setting a console toggle switch, not a support program. In 1963, when microcode was first used to speed up this simulation process, IBM engineers coined the term "emulator" to describe the concept. In the 2000s, it has become common to use the word "emulate" in the context of software. However, before 1980, "emulation" referred only to emulation with a hardware or microcode assist, while "simulation" referred to pure software emulation.[25] For example, a computer specially built for running programs designed for another architecture is an emulator. In contrast, a simulator could be a program which runs on a PC, so that old Atari games can be simulated on it. Purists continue to insist on this distinction, but currently the term "emulation" often means the complete imitation of a machine executing binary code while "simulation" often refers to computer simulation, where a computer program is used to simulate an abstract model. Computer simulation is used in virtually every scientific and engineering domain and Computer Science is no exception, with several projects simulating abstract models of computer systems, such as network simulation, which both practically and semantically differs from network emulation.[26] Quelle: https://en.wikipedia.org/wiki/Emulator#Comparison_with_simulation
Für mich passt die Bezeichnung nicht. Er beschreibt einen Emulator. Übrigens ist für mich auch die dort erwähnte Java Virtual Machine eigentlich keine VM.
georg schrieb: > Das ist eher der Verwendungszweck, Simulator nimmt > man zur Entwicklung, Emulator ist für Dauereinsatz Ich weiß nicht, ob ich dem so zustimmen möchte. Bochs wurde lange Zeit als "Simulator" betitelt, in Abgrenzung zu Qemu wegen dessen JIT-Komponente (das war vor KVM bzw. kqemu). EPROM-Emulatoren sind auch reine Entwicklerwerkzeuge. Defino schrieb: > Bei VHDL stecke ich noch in den Grundlagen > und habe keine Erfahrung damit. Ich wollte dich nicht zu VHDL schicken, sondern dir zeigen, dass man durchaus auch dann von einem Simulator (bzw. Emulator) spricht, wenn es die zu simulierende/emulierende Umgebung nicht real gibt. Defino schrieb: > Dort wird keine Virtualisierungstechnik wie in VirtualBox genutzt. > Sondern nur die LC-3 Architektur simuliert. Trotzdem spricht der > Autor von einer virtual machine. Naja, die JVM (Java Virtual Machine) macht auch nichts anderes. Ich würde einfach mal behaupten, dass die Definitionen fließend (oder verwässert) sind.
S. R. schrieb: > Naja, die JVM (Java Virtual Machine) macht auch nichts anderes. > > Ich würde einfach mal behaupten, dass die Definitionen fließend (oder > verwässert) sind. Streng genommen lässt sich die Definition von "virtual machine" als eine klar abgrenzbare Virtualisierungstechnik nicht erzwingen. Es kann sich historisch zwar so entwickeln, aber die bisherige Entwicklung hat offenbar zu keiner eindeutigen scharfen Differenzierung geführt. Vielleicht braucht es noch Zeit :D Die beiden Worte "virtuell" und "Maschine" sind immer noch durchaus legitime Beschreibungen einer unechten Entität, also einer virtuellen Maschine. Wie es auch bei der JVM so bezeichnet werden kann.
Defino schrieb: > Die beiden Worte "virtuell" und "Maschine" sind immer noch durchaus > legitime Beschreibungen einer unechten Entität, also einer virtuellen > Maschine. Wie es auch bei der JVM so bezeichnet werden kann. Das trifft dann aber auf alles, was wir hier diskutiert haben, zu. Wenn man das wörtlich nimmt, wäre auch das Auto in einem Rennspiel eine virtuelle Maschine, denn das Wort "Maschine" sagt ja dann noch nicht, dass es ein Computer sein muss. So kommt man also nicht weiter. Der Gesamtbegriff "virtuelle Maschine" hat ganz offenbar eine deutlich konkretere Bedeutung als nur die Zusammenführung der zwei Wörter.
Rolf M. schrieb: > Das trifft dann aber auf alles, was wir hier diskutiert haben, zu. Wenn > man das wörtlich nimmt, wäre auch das Auto in einem Rennspiel eine > virtuelle Maschine, denn das Wort "Maschine" sagt ja dann noch nicht, > dass es ein Computer sein muss. So kommt man also nicht weiter. Der > Gesamtbegriff "virtuelle Maschine" hat ganz offenbar eine deutlich > konkretere Bedeutung als nur die Zusammenführung der zwei Wörter. Gegenwärtig scheint es mehr als eine Bedeutung zu geben während manche versuchen eine Bedeutung zu etablieren. Ohne ein zentrale Instanz die das definieren kann, ist es auch nicht ganz einfach, jemandem zu sagen dass seine Definition falsch ist. Es wird sich wohl historisch irgendwie entwickeln und dabei kann es durchaus weiterhin mehrdeutig bleiben. Manche betrachten solche Überlegungen vielleicht als alberne Zeitverschwendung. Aber eigentlich ist es interessant die Definition von Begriffen soweit wie möglich zu schärfen. Und dadurch ein besseres Verständnis der dahinter liegenden Konzepte zu entwickeln.
Defino schrieb: > Manche betrachten solche Überlegungen vielleicht > als alberne Zeitverschwendung. Wenn man Philosoph ist, nicht.
S. R. schrieb: > Defino schrieb: >> Manche betrachten solche Überlegungen vielleicht >> als alberne Zeitverschwendung. > > Wenn man Philosoph ist, nicht. Oder wenn man jemand ist, der Standards definiert. Dafür ist nämlich eine präzise Definition und Abgrenzung unterschiedlicher Begriffe Grundvoraussetzung.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.