Seite 8 von 8

Re: Emulator in Python...

Verfasst: Dienstag 1. September 2015, 09:46
von jens
jerch hat geschrieben:Gibts eigentlich einen speziellen Grund, warum die Registerbits vorher auf eins gesetzt werden? Hätte ja erwartet, dass die genullt werden.
Keine Ahnung. Ich hab es auch immer noch nicht auf dem echten Computer nach geprüft...

Allerdings ist es so, das beim "nullen" die unittests nicht durchlaufen. z.B. der mit der CRC32 Berechnung.
Von daher gehe ich davon aus, das es so richtig ist.

Allerdings ist mit dennoch ein Fehler aufgefallen! Das Konvertieren von 16Bit zu einem 8Bit, führt zu einem falschen Ergebnis!
Zumindest intern in der Methode. Hinterher ist es IMHO egal, weil ein 8Bit Register beim setzten, eh den Wert abschneidet.
Dazu kommt noch, das der DocString falsch war...

Siehe: https://github.com/6809/MC6809/commit/5 ... a052ec73e9

EDIT: Mir ist noch aufgefallen, das der aktuelle code ein wenig umständlich ist. Deswegen: https://github.com/6809/MC6809/commit/2 ... 0dfcf40c10

Kannst du deinen Pull aktualisieren?

Re: Emulator in Python...

Verfasst: Mittwoch 2. September 2015, 20:53
von jens
@jerch: ich hab mir jetzt dein https://github.com/6809/MC6809/pull/1/files näher angesehen...

Was mir nicht gefällt sind die ganzen & register.BASE

Dann hab ich mich gefragt, was ist eigentlich schneller:

Code: Alles auswählen

if n>0xff:
    x = n & 0xff
else:
    x = n
oder:

Code: Alles auswählen

x = n & 0xff
Hab timeit angeworfen:

Code: Alles auswählen

from timeit import Timer
import sys


# TEST_DATA = [0xff] * 10000
# TEST_DATA += [0x100] * 10000
# test1: 1.441sec
# test2: 1.434sec


TEST_DATA = [0xff] * 20000
TEST_DATA += [0x100] * 2000
# test1: 1.139sec
# test2: 1.593sec


def test1():
    for n in TEST_DATA:
        if n>0xff:
            x = n & 0xff
        else:
            x = n

def test2():
    for n in TEST_DATA:
        x = n & 0xff


if __name__ == "__main__":

    def timeit(func, number):
        name = func.__name__
        sys.stdout.write("%20s: " % name)
        sys.stdout.flush()
        t = Timer("%s()" % name, setup="from __main__ import %s" % name)
        print("%.3fsec" % t.timeit(number))

    number = 1000
    timeit(test1, number)
    timeit(test2, number)
Also, wenn ein Überlauf nicht so häufig vorkommt, dann ist die if-Variante schneller.
Ich gehe einfach mal davon aus, das es in der Praxis nicht so oft vor kommt.

Deswegen hab ich mal einen Testlauf mit dem Benchmark gemacht.
Dazu hab ich den 'master' branch genommen und https://github.com/6809/MC6809/blob/5da ... py#L63-L91 noch abgeändert.
Also diese beiden Varianten gegeneinander Verglichen:

Code: Alles auswählen

class ValueStorage8Bit(ValueStorage):
    def set(self, v):
        if v > 0xff:
            v = v & 0xff
        self.value = v
        return v # e.g.: r = operand.set(a + 1)


class ValueStorage16Bit(ValueStorage):
    def set(self, v):
        if v > 0xffff:
            v = v & 0xffff
        self.value = v
        return v # e.g.: r = operand.set(a + 1)

Code: Alles auswählen

class ValueStorage8Bit(ValueStorage):
    def set(self, v):
        v = v & 0xff
        self.value = v
        return v # e.g.: r = operand.set(a + 1)


class ValueStorage16Bit(ValueStorage):
    def set(self, v):
        v = v & 0xffff
        self.value = v
        return v # e.g.: r = operand.set(a + 1)

Leider schwanken die Benchmark Werte so stark, das man keine genaue Aussage treffen kann :?

Re: Emulator in Python...

Verfasst: Mittwoch 2. September 2015, 22:33
von jerch
Ja das ist nicht hübsch und auch der Grund, warum ich mit ctypes Typen rumprobiert hatte.

Bitte nimm die Änderungen nicht zu ernst, das sind größtenteils quick&dirty Ersetzungen, um die Flaschenhälse im profiling zu bessern. In einem zweiten Ansatz habe ich auch die generierten Instruktionen durch eine einfachere Abstraktion ersetzt, was aber nicht mehr viel bringt. Ein Ansatz mit Megaloop bringt auch nichts, dafür fehlt Python ein switch-statement in O(1). Das Funktionsmapping ist da schon das beste und auch viel lesbarer. Wenn ich dazu komm, räum ich die Änderungen nochmal auf und leg es ins Repo. Dann kannst Du schauen, ob Du was davon übernehmen willst.

Re: Emulator in Python...

Verfasst: Donnerstag 3. September 2015, 14:28
von jens
Ich hab nun den "mixin" CPU branch in "master" gemerged.
jerch hat geschrieben:Bitte nimm die Änderungen nicht zu ernst, das sind größtenteils quick&dirty Ersetzungen, um die Flaschenhälse im profiling zu bessern.
Außerdem hab ich ein paar deiner Vorschläge aufgenommen. z.B. ein Teil der CC Register Klasse und den Verzicht auf .get():
https://github.com/6809/MC6809/commit/3 ... d742516562

Re: Emulator in Python...

Verfasst: Donnerstag 3. September 2015, 16:28
von jens
So und die CC Register direkt in die CPU einpflanzen per mixin hab ich nun mit https://github.com/6809/MC6809/commit/b ... 719df9cbd7 angegangen...

Jetzt muß ich allerdings DragonPy anpassen...

Re: Emulator in Python...

Verfasst: Donnerstag 3. September 2015, 19:18
von darktrym
Gibts denn mittlerweile Audio im Emulator?

Re: Emulator in Python...

Verfasst: Donnerstag 3. September 2015, 20:32
von jens
Nein. Grundsätzlich möglich, halte ich es allerdings schon...

Re: Emulator in Python...

Verfasst: Donnerstag 11. Februar 2016, 18:25
von jens
Wer mich mal sehen will... Vom letzten Python Treffen in Düsseldorf über DragonPy: https://www.youtube.com/watch?v=GFuxPDo ... xKeV1ZxL22