Forum: PC Hard- und Software Unterschiede zwischen Emulator und Virtueller Maschine?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Defino (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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

von knoxX (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Defino schrieb:
> Hardware simuliert

Ein Hardwaresimulator

von knoxX (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Defino schrieb:
> Wäre es systembasiert oder prozessbasiert?

Um bei deiner Definition zu bleiben: weder noch, da es keine 
Virtualisierung ist sondern eine Emulation;)

von knoxX (Gast)


Bewertung
1 lesenswert
nicht lesenswert
JVM ist ein bytecode-Interpreter

von Eigentlich nicht da (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von KknoxX (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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*

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Eigentlich nicht da (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Carl D. (jcw2)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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
von georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von (prx) A. K. (prx)


Bewertung
3 lesenswert
nicht lesenswert
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
von Interreso (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Ich hätte da noch die "abstract virtual machine" der C Standards.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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
von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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).

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Larry (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> 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?

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
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
von rbx (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Defino (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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.

von georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Defino (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Defino (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Defino (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Defino (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Defino (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Defino schrieb:
> Manche betrachten solche Überlegungen vielleicht
> als alberne Zeitverschwendung.

Wenn man Philosoph ist, nicht.

von Rolf M. (rmagnus)


Bewertung
1 lesenswert
nicht lesenswert
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.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Touché.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.