Optimiert(est)er peek für einen unsigned long 32bit

Für allgemeine Fragen zur Programmierung mit PureBasic.
Benutzeravatar
STARGÅTE
Kommando SG1
Beiträge: 7028
Registriert: 01.11.2005 13:34
Wohnort: Glienicke
Kontaktdaten:

Re: Optimiert(est)er peek für einen unsigned long 32bit

Beitrag 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
PB 6.01 ― Win 10, 21H2 ― Ryzen 9 3900X, 32 GB ― NVIDIA GeForce RTX 3080 ― Vivaldi 6.0 ― www.unionbytes.de
Aktuelles Projekt: Lizard - Skriptsprache für symbolische Berechnungen und mehr
Benutzeravatar
NicTheQuick
Ein Admin
Beiträge: 8807
Registriert: 29.08.2004 20:20
Computerausstattung: Ryzen 7 5800X, 64 GB DDR4-3200
Ubuntu 24.04.2 LTS
GeForce RTX 3080 Ti
Wohnort: Saarbrücken

Re: Optimiert(est)er peek für einen unsigned long 32bit

Beitrag von NicTheQuick »

Regenduft hat geschrieben:@ NicTheQuick: Erst gacken und dann nicht legen... Tse! :wink:
Ja, der Code geht ja noch nicht. :D

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. :)
Benutzeravatar
STARGÅTE
Kommando SG1
Beiträge: 7028
Registriert: 01.11.2005 13:34
Wohnort: Glienicke
Kontaktdaten:

Re: Optimiert(est)er peek für einen unsigned long 32bit

Beitrag 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
PB 6.01 ― Win 10, 21H2 ― Ryzen 9 3900X, 32 GB ― NVIDIA GeForce RTX 3080 ― Vivaldi 6.0 ― www.unionbytes.de
Aktuelles Projekt: Lizard - Skriptsprache für symbolische Berechnungen und mehr
Benutzeravatar
NicTheQuick
Ein Admin
Beiträge: 8807
Registriert: 29.08.2004 20:20
Computerausstattung: Ryzen 7 5800X, 64 GB DDR4-3200
Ubuntu 24.04.2 LTS
GeForce RTX 3080 Ti
Wohnort: Saarbrücken

Re: Optimiert(est)er peek für einen unsigned long 32bit

Beitrag 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.
melow
Beiträge: 32
Registriert: 04.02.2006 05:05
Wohnort: Thailand

Re: Optimiert(est)er peek für einen unsigned long 32bit

Beitrag 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?
Benutzeravatar
STARGÅTE
Kommando SG1
Beiträge: 7028
Registriert: 01.11.2005 13:34
Wohnort: Glienicke
Kontaktdaten:

Re: Optimiert(est)er peek für einen unsigned long 32bit

Beitrag 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!
PB 6.01 ― Win 10, 21H2 ― Ryzen 9 3900X, 32 GB ― NVIDIA GeForce RTX 3080 ― Vivaldi 6.0 ― www.unionbytes.de
Aktuelles Projekt: Lizard - Skriptsprache für symbolische Berechnungen und mehr
Benutzeravatar
Danilo
-= Anfänger =-
Beiträge: 2284
Registriert: 29.08.2004 03:07

Re: Optimiert(est)er peek für einen unsigned long 32bit

Beitrag 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.
cya,
...Danilo
"Ein Genie besteht zu 10% aus Inspiration und zu 90% aus Transpiration" - Max Planck
Benutzeravatar
STARGÅTE
Kommando SG1
Beiträge: 7028
Registriert: 01.11.2005 13:34
Wohnort: Glienicke
Kontaktdaten:

Re: Optimiert(est)er peek für einen unsigned long 32bit

Beitrag 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
PB 6.01 ― Win 10, 21H2 ― Ryzen 9 3900X, 32 GB ― NVIDIA GeForce RTX 3080 ― Vivaldi 6.0 ― www.unionbytes.de
Aktuelles Projekt: Lizard - Skriptsprache für symbolische Berechnungen und mehr
Benutzeravatar
Danilo
-= Anfänger =-
Beiträge: 2284
Registriert: 29.08.2004 03:07

Re: Optimiert(est)er peek für einen unsigned long 32bit

Beitrag 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
cya,
...Danilo
"Ein Genie besteht zu 10% aus Inspiration und zu 90% aus Transpiration" - Max Planck
Nino
Beiträge: 1300
Registriert: 13.05.2010 09:26
Wohnort: Berlin

Re: Optimiert(est)er peek für einen unsigned long 32bit

Beitrag von Nino »

Einzelheiten über "scratch registers" etc. siehe Calling conventions, S. 10 ff.: Register usage
Antworten