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.
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.
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
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.
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.
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.
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.
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.
