Seite 1 von 1
inter Prozess Kommunikation...
Verfasst: Mittwoch 30. Oktober 2013, 22:00
von jens
In DragonPy started quasi die GUI per subprocess die CPU, hier:
https://github.com/jedie/DragonPy/blob/ ... py#L49-L74
Beide unterhalten sich dann über sockets:
https://github.com/jedie/DragonPy/blob/ ... y#L86-L125
Dabei wird Frage/Antwort per struct.pack() und struct.unpack() gemacht.
Dazu wird ein recht einfaches Format verwendet:
Code: Alles auswählen
STRUCT_TO_PERIPHERY_FORMAT = (# For sending data to periphery
"<" # little-endian byte order
"I" # CPU cycles - unsigned int (integer with size: 4)
"I" # op code address - unsigned int (integer with size: 4)
"B" # action: 0 = read, 1 = write - unsigned char (integer with size: 1)
"B" # structure: 0 = byte, 1 = word - unsigned char (integer with size: 1)
"H" # Address - unsigned short (integer with size: 2)
"H" # Bytes/Word to write - unsigned short (integer with size: 2)
)
Das ganze kommt vom Ursprünglichen ApplePy Projekt.
Flexibel ist das ja nicht gerade, aber ich frage mich ob es eine gute und effektiver Weg ist?
Re: inter Prozess Kommunikation...
Verfasst: Mittwoch 30. Oktober 2013, 22:38
von EyDu
Kommt für dich der Weg über
Sockets im multiprocessing-Modul in Frage?
Re: inter Prozess Kommunikation...
Verfasst: Donnerstag 31. Oktober 2013, 00:31
von jens
Danke!
Das wäre eine Idee wert, denn das Beispiel sieht auch recht einfach aus (gekürzt):
server:
Code: Alles auswählen
from multiprocessing.connection import Listener
address = ('localhost', 6000) # family is deduced to be 'AF_INET'
listener = Listener(address, authkey='secret password')
conn = listener.accept()
print 'connection accepted from', listener.last_accepted
conn.send([2.25, None, 'junk', float])
conn.close()
listener.close()
client:
Code: Alles auswählen
from multiprocessing.connection import Client
address = ('localhost', 6000)
conn = Client(address, authkey='secret password')
print conn.recv() # => [2.25, None, 'junk', float]
conn.close()
Gerade interessant dabei ist
send:
http://docs.python.org/2/library/multip ... ction.send
Wobei pickle verwendet wird.
Denke mal alles im allem wird es langsamer, aber wesentlich flexibler...
Ich sollte mir mal generell das multiprocessing Modul ansehen. Denn z.Z. wird der CPU Prozesse mir subprocess "per Hand" gestartet.
Re: inter Prozess Kommunikation...
Verfasst: Donnerstag 31. Oktober 2013, 14:30
von jerch
@jens:
Per se finde ich die Idee gut, die CPU in einem separaten Prozess laufen zu lassen. Deine ersten Benchmarkzahlen im anderen Thread deuten an, das die CPU-Emulation zum Flaschenhals werden könnte (zumindest für CPython, da ist zwar noch einiges an Optimierungsspielraum, wie ich Dir schon gesagt hatte, aber eine Verdreifachung ist wohl eher unwahrscheinlich). Durch die Prozesstrennung kannst Du die Komponenten z.B. durch nice-Level besser aufeinander abstimmen. Allerdings kann die CPU nur sinnvoll "ticken", wenn die Peripherie auch schnell genug die Daten bereitstellt bzw. abholt. Spätestens bei Spielen mit Soundausgabe (Hatte der Dragon eigentlich Sound?) und internen Timern wirds dann so richtig kniffelig, da die CPU massiven Taktschwankungen unterliegt, die Du teuer korrigieren musst, damit z.B. die Soundausgabe noch anhörbar ist.
(Stichwort realtime, unter heutigem Windows/Linux weisst Du nicht, wann Dein CPU-Prozess wieder ein paar Takte rechnen darf)
Grundsätzlich würde ich an Deiner Stelle versuchen, jede der Komponenten mit so wenig wie möglich Bloatware umzusetzen. Mit Highlevel-Schnittstellen (oder Modulen) kommst Du zwar in der Entwicklung schnell voran, diese können aber in der Summe dazu führen, dass der Emulator unbenutzbar ist und Du große Teile umschreiben musst. In puncto Kommunikation würde ich es pragmatisch angehen - hast Du eine funktionierende Variante, entwickle damit weiter. Zeichnet sich ab, dass die Kommunikation zum Flaschenhals wird, musst Du hier abrüsten. Eine zusätzliche Abstraktion über z.B. ein Drittmodul würde ich ohne Not aus obigen Gründen nicht einführen.
Re: inter Prozess Kommunikation...
Verfasst: Donnerstag 31. Oktober 2013, 15:19
von jens
Danke für deine Hinweise... Allerdings ist mein Ziel eh nicht, das es ein vollständiger und Timing genauer Emulator wird. Wozu auch? Den gibt es bereits in Form von XRoar (
http://www.6809.org.uk/dragon/xroar.shtml ) und MESS (
http://mess.org/ ) und jetzt neu, auch in JavaScript mit JMESS:
http://jsmess.textfiles.com/
Mein erstes Ziel ist erst mal nur die Lauffähigkeit des BASIC Interpreters.
Dann will ich lieber das machen, was XRoar und MESS nicht machen: Einfache Interaktion mit dem Emulator: z.B. einen separaten BASIC Editor-Fenster, bei den man normal coden kann und per klick wird der Code in den Speicher des Emulators geladen und ausgeführt.
Ob ich überhaupt Sound und Grafik-Ausgabe mache, weiß ich noch nicht.
Das ganze ist auch ehr für mich zum lernen Gedacht und dafür hat es sich für mich schon definitiv gelohnt
Re: inter Prozess Kommunikation...
Verfasst: Donnerstag 31. Oktober 2013, 17:33
von jens
Hab die aktuelle Implementierung versucht in Worte zu fassen:
https://github.com/jedie/DragonPy/#about-implementation
Dazu noch ein Diagramm:
Code: Alles auswählen
+----------+ +----------+ +--------------------+
| CLI | start via | 6809 CPU | start in | CPU control server |
|----------|-------------->|----------|+------------>|--------------------|
| | subprocess | | same process | |
| | | | | http server |
|periphery | | | | |
|-Screen |bus communicate|bus Memory|<-------------| localhost:6809 |
|-SAM/PIA |<------------->| area | | |
|-cassette | via socket | | | |
+----------+ +----------+ +--------------------+
(Das habe ich bei
http://www.asciiflow.com gemacht)