ASM + Modulo

H.Brill

Hallo, ich suche ein Modulo, das auch (oder auch nur) mit Fließkommazahlen klar kommt.

Das normale X% MOD Y% arbeitet ja nur mit Integerzahlen.

Da es auch schnell sein muß, käme mir ein ASM-Proc recht. Da der Inline-Assembler ja

auch FPU - Befehle kann, denke ich, daß sowas hin zu bekommen ist.

Vielleicht haben ja die Forumsmitglieder, die sich besser als ich in ASM auskennen,

wie z.B. Volkmar oder p.Specht, eine Idee.

Jens-Arne

Hallo Heinz,

ich habe das als fbPROC realisiert (JRPC3 erforderlich). Aber keine Angst, wenn Du JRPC3 nicht benutzen möchtest, ist die erzeugte native DLL hier beigefügt:

Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

Code

{$FbSyntax On}
{$SetFbDllName fmod}

fbPROC fmod(ByRef a As Double,ByRef b As Double,ByRef erg As Double) As Integer Export
  dim c As Double
  dim As LongInt x,y,z
  x=int(a)
  y=int(b)+1
  z=int(x/y) 'Multiplikator, der auf jeden Fall noch nicht ins Negative führt
  c=a-(b*z) 'diese Subtraktion beschleunigt die Ergebnissuche, da sie schon sehr nah ans Ziel führt
  while c>=b 'jetzt noch b solange vom übriggebliebenen Rest von a abziehen, bis wir das Ergebnis haben
    c=c-b
  endwhile
  erg=c
  return 1
ENDPROC 'fmod

fbPROC smod(ByVal a As Single,ByVal b As Single) As Integer Export
  dim c As Single
  dim As LongInt x,y,z
  dim erg As Integer
  x=int(a)
  y=int(b)+1
  z=int(x/y) 'Multiplikator, der auf jeden Fall noch nicht ins Negative führt
  c=a-(b*z) 'diese Subtraktion beschleunigt die Ergebnissuche, da sie schon sehr nah ans Ziel führt
  while c>=b 'jetzt noch b solange vom übriggebliebenen Rest von a abziehen, bis wir das Ergebnis haben
    c=c-b
  endwhile
  poke single,@erg,c
  return erg
ENDPROC 'fmod

declare f1!,f2!,erg!
declare single s1,s2,serg

cls
f1!=52.2
f2!=5.151
fmod(@addr(f1!),@addr(f2!),@addr(erg!)) 'die DLL-Funktion heißt "FMOD@12" (großgeschrieben)
print erg!
s1=52.2
s2=5.151
serg=smod(s1,s2) 'die DLL-Funktion heißt "SMOD@8" (großgeschrieben) - das Ergebnis muss einer single-Variablen zugewiesen werden, da es sonst als Integer interpretiert wird
print serg
waitinput
end

Alles anzeigen

Die Funktion FMOD@12 erwartet zwei Float-Werte. Da diese 8 Byte breit sind, DLL-Funktionsparameter aber stets 4 Byte breit sein müssen, sind hier die beiden zu verarbeitenden Werte als deren Adressen zu übergeben und als dritter Parameter die Adresse eines Float-Wertes, der das Ergebnis aufnimmt.

Die Funktion SMOD@8 arbeitet mit Single-Werten, die 4 Byte breit sind und daher direkt übergeben werden können (nur zwei Parameter). Allerdings ist die Genauigkeit natürlich auch schlechter.

Beste Grüße, Jens-Arne

Jens-Arne

Und hier noch eine Version mit abgefangenem "Division durch null"-Fehler:

Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

Code

{$FbSyntax On}
{$SetFbDllName fmod}

fbPROC fmod(ByRef a As Double,ByRef b As Double,ByRef erg As Double) As Integer Export
  dim c As Double
  dim As LongInt x,y,z
  if b=0
    messagebox(0,"fmod: Division durch null.","Division durch null",0)
    erg=-1
    return 0
  else
    x=int(a)
    y=int(b)+1
    z=int(x/y) 'Multiplikator, der auf jeden Fall noch nicht ins Negative führt
    c=a-(b*z) 'diese Subtraktion beschleunigt die Ergebnissuche, da sie schon sehr nah ans Ziel führt
    while c>=b 'jetzt noch b solange vom übriggebliebenen Rest von a abziehen, bis wir das Ergebnis haben
      c=c-b
    endwhile
    erg=c
    return 1
  endif
ENDPROC 'fmod

fbPROC smod(ByVal a As Single,ByVal b As Single) As Integer Export
  dim c As Single
  dim As LongInt x,y,z
  dim erg As Integer
  if b=0
    messagebox(0,"smod: Division durch null.","Division durch null",0)
    poke single,@erg,-1
  else
    x=int(a)
    y=int(b)+1
    z=int(x/y) 'Multiplikator, der auf jeden Fall noch nicht ins Negative führt
    c=a-(b*z) 'diese Subtraktion beschleunigt die Ergebnissuche, da sie schon sehr nah ans Ziel führt
    while c>=b 'jetzt noch b solange vom übriggebliebenen Rest von a abziehen, bis wir das Ergebnis haben
      c=c-b
    endwhile
    poke single,@erg,c
  endif
  return erg
ENDPROC 'fmod

declare f1!,f2!,erg!
declare single s1,s2,serg

cls
f1!=52.2
f2!=5.151
fmod(@addr(f1!),@addr(f2!),@addr(erg!)) 'die DLL-Funktion heißt "FMOD@12" (großgeschrieben)
print erg!
s1=52.2
s2=5.151
serg=smod(s1,s2) 'die DLL-Funktion heißt "SMOD@8" (großgeschrieben) - das Ergebnis muss einer single-Variablen zugewiesen werden, da es sonst als Integer interpretiert wird
print serg
waitinput
end

Alles anzeigen

H.Brill

Danke,

Single-Genauigkeit reicht mir da völlig.

Wenn mal nicht, kann man ja mit Double() zuerst konvertieren.

Jens-Arne

Hallo nochmal,

ich habe gerade festgestellt, dass die Single-Variante auch schneller ist als die genauere Float-Variante (ca. ein viertel).

Da Du sagtest, dass es Dir auf Geschwindigkeit ankommt, wäre aber zu erwägen, dass Du die gesamte Berechnung in einer fbPROC ausführst. Denn jeder Funktionsaufruf benötigt aufgrund von Registergeschiebe Zeit, sodass es besser wäre, nur eine Funktion aufzurufen und darin alles zu berechnen, was es zu berechnen gibt, als innerhalb einer Schleife tausendfach die eine Funktion aufzurufen, die nur die Modulo-Funktion ausführt.

Zum Vergleich:

10.000 Mal smod aus einer Profan-Schleife aufrufen: 268ms

10.000 Mal smod-Berechnung innerhalb einer fbPROC: 0ms (!!! - also "off scale low")

Im ersten Fall kosten also keinesfalls die Berechnungen an sich irgendeine messbare Zeit, sondern allein die 10.000 Funktionsaufrufe.

Allerdings ist das immer noch viel besser, als das in reinem XProfan zu schreiben (2 Sekunden).

Vermutlich ist die Single-Variante von außen gesehen auch nur deshalb schneller, weil sie einen Parameter weniger hat.

Gruß, Jens-Arne

p. specht

Interessant! Was kommt dann bei Pi() mod exp(1) raus? Und ist das Ergebnis bei "unendiich" langen Kommastellen sinnvoll?

Jens-Arne

Naja, die Grenzen von Gleitkommaoperationen sollte man schon kennen, wenn man diese Funktion verwendet. Pi ist z.B. überhaupt nicht als Gleitkommazahl darstellbar (nicht exakt jedenfalls). Mir reicht aber für alle Lebenslagen die grobe Approximierung 3,14159. Da wird das Ei schon rund werden.

Jetzt mitmachen!