Seite 4 von 5
Re: Optimiert(est)er peek für einen unsigned long 32bit
Verfasst: 03.09.2013 12:00
von STARGÅTE
Aber nicht wenn ich in ASM selbst Push benutzte.
Ich kann dann zwar:
Code: Alles auswählen
MOV ecx, *Input ; Leseadresse
MOV edi, Result ; Schreibadresse
benutzen, weil PB dann *Input versteht, aber am Ende wird es ja trotzdem in esp+... übersetzt und dann wäre der Fehler trotzdem da. Zumindest musste ich eben auch den Stack anpassen, als ich den Code für InlineASM umgeschrieben habe
Re: Optimiert(est)er peek für einen unsigned long 32bit
Verfasst: 03.09.2013 12:23
von NicTheQuick
Regenduft hat geschrieben:@ NicTheQuick: Erst gacken und dann nicht legen... Tse!
Ja, der Code geht ja noch nicht.
Und außerdem quäle ich mich hier mit x64 herum. Auf x86 schaue ich mittlerweile nur herablassend herunter. :P Das würde allein schon wegen meinem RAM nicht in Frage kommen. ^^
@Stargate:
Also sehe ich das dann richtig, dass dein Code nur mit komplizierteren Anpassungen auf einem x64-System laufen würde?
Ich kriege ja schon direkt erst mal ASM-Fehler wegen unterschiedlicher Registergrößen. Das erscheint mir etwas unpraktisch. Eventuell kann ja vielleicht auch noch was mit MMX heraus kitzeln.
Re: Optimiert(est)er peek für einen unsigned long 32bit
Verfasst: 03.09.2013 12:35
von STARGÅTE
Nein, das siehst du falsch.
Ungetestet (bin gerade in der UNI) sollte das hier funktionieren:
Code: Alles auswählen
!MOV ebx, 85 ; Divisor
!MOV rcx, [p.p_Input] ; Leseadresse
!MOV rdi, [p.v_Result] ; Schreibadresse
!SUB rcx, [p.v_Length]
!base85_loop:
!MOV eax, [rcx] ; Tiefer Dividend-Teil
!BSWAP eax
!MOV edx, 0 ; Hoher Dividend-Teil = 0
!DIV ebx ; Erste Division
!ADD [rdi+4], dl ; Rest (nur das tiefste Byte) kommt in den String, addiert auf das "!"
!MOV edx, 0
!DIV ebx ; Zweite Division
!ADD [rdi+3], dl
!MOV edx, 0
!DIV ebx ; Dritte Division
!ADD [rdi+2], dl
!MOV edx, 0
!DIV ebx ; Vierte Division
!ADD [rdi+1], dl
!MOV edx, 0
!DIV ebx ; Fünfte Division
!ADD [rdi+0], dl
!ADD rcx, 4 ; Leseadresse + 4
!ADD rdi, 5 ; Schreibadresse + 5
!CMP rcx, [p.p_Input] ; Fertig?
!JNZ base85_loop
Re: Optimiert(est)er peek für einen unsigned long 32bit
Verfasst: 03.09.2013 12:44
von NicTheQuick
Hm... Das hat so nicht funktioniert. Zumindest ist gerade Purebasic abgestürzt, weil der Debugger nicht mehr geantwortet hat. Allerdings war dort auch in einer Zeile eine ewig lange Zeichenkette zu sehen.
Aber ich versuche es gleich noch mal mit einem entschärften Debug mit Stringlängenbegrenzung.
Re: Optimiert(est)er peek für einen unsigned long 32bit
Verfasst: 03.09.2013 12:50
von melow
Frage in die Runde: Hab ich es richtig verstanden daß wenn man (in PB) Inline ASM benützt, man auf den Inhalt mancher Register aufpassen muss weil diese von PB nach dem eigenem ASM Code ja weiterhin benützt werden?
Ohh... da muss man dann aber höllisch aufpassen... richtig?
Re: Optimiert(est)er peek für einen unsigned long 32bit
Verfasst: 03.09.2013 12:54
von STARGÅTE
Ja, offiziell frei zur benutzung sind nur eax, ecx und edx.
Alle anderen (wenn du sie benutzt) müssen/sollten gesichert werden.
Bislang hatte ich aber keine Probleme feststellen können, wenn ich auch ebx ungesichert genutzt habe.
Aber nur weils kein Fehler erzeugt, heißt dass ja nicht, dass es kein erzeugen könnte!
Re: Optimiert(est)er peek für einen unsigned long 32bit
Verfasst: 03.09.2013 13:03
von Danilo
STARGÅTE hat geschrieben:Ja, offiziell frei zur benutzung sind nur eax, ecx und edx.
Wo steht das denn in der PB-Hilfe?
PB kann (in Zukunft) alle Register in generierten Prozeduren benutzen wie es will.
So wie jeder andere Compiler.
Oder meinst Du speziell die WinAPI Aufrufkonvention? Auch die muss PB intern
nicht beachten, solange es nur intern ist. Das ist dann nur bei WinAPI-Aufrufen wichtig,
bzw. bei etlichen externen Aufrufen auf dem Betriebssystem Windows.
Re: Optimiert(est)er peek für einen unsigned long 32bit
Verfasst: 03.09.2013 13:21
von STARGÅTE
http://www.purebasic.com/german/documen ... edasm.html
- Die verwendbaren Register sind: eax, edx und ecx. Alle anderen müssen immer reserviert bleiben.
Damit ist gemeint, dass diese nie Inhalte haben, die "später" Wichtig sind, es sind halt die Arbeitsregister.
- Lokale Variablen in PureBasic werden direkt durch den Stack-Pointer indexiert, was bedeutet: Wenn der Stack-Pointer durch eine ASM Anweisung (wie PUSH, POP etc.) verändert wird, dann wird der Variablen-Index fehlerhaft sein und ein direkter Verweis auf Variablen funktioniert nicht mehr.
Hier auch noch der Hinweis wegen PUSH und POP
Re: Optimiert(est)er peek für einen unsigned long 32bit
Verfasst: 03.09.2013 13:34
von Danilo
STARGÅTE hat geschrieben:http://www.purebasic.com/german/documen ... edasm.html
- Die verwendbaren Register sind: eax, edx und ecx. Alle anderen müssen immer reserviert bleiben.
Damit ist gemeint, dass diese nie Inhalte haben, die "später" Wichtig sind, es sind halt die Arbeitsregister.
OK, werde das jetzt nicht überprüfen. Ein Überfliegen dieser Seite zeigt schon etliche Fehler. Zum Beispiel der
Bezug aus FASM (Mac OS X 64bit verwendet yasm) und Bezug auf 32bit Register reicht schon aus. Scheint schon
auf den ersten Blick vollkommen alt/falsch zu sein.
EDIT:
Bug Reports >> Bugs - Documentation >> documentation/reference/inlinedasm.html
Re: Optimiert(est)er peek für einen unsigned long 32bit
Verfasst: 03.09.2013 14:59
von Nino
Einzelheiten über "scratch registers" etc. siehe
Calling conventions, S. 10 ff.: Register usage