Seite 5 von 5
Re: Optimiert(est)er peek für einen unsigned long 32bit
Verfasst: 03.09.2013 16:02
von Regenduft
Habe gerade mal spaßeshalber die PureBasic-Hilfe aus meinem ältesten verfügbaren Backup (PureBasic 4.40 beta 6, 24.11.2009) entpackt und muss sagen, dass der InlineASM-Teil kaum wiederzuerkennen ist!
Hier die
komplette Liste der Änderungen:
Hinzugefügt:
- Wird die Sprungmarke innerhalb einer Prozedur definiert, dann lautet ihr Präfix 'l_procedurename_', in Kleinbuchstaben.
Geändert:
- "Beispiel:" in "Beispiel",
- "Beispiel:" in "Beispiel" und
- "Beispiel:" in "Beispiel"
Re: Optimiert(est)er peek für einen unsigned long 32bit
Verfasst: 03.09.2013 17:54
von Thorium
Wenn man pusht muss man nicht den Stackpointer anpassen. Kann man zwar, scheint mir aber etwas gefährlich zu sein. Man kann einfach die Anzahl der gepushten Bytes zur Addressierung addieren, z.B.: "!MOV ecx, [p.p_Input+8]"
Re: Optimiert(est)er peek für einen unsigned long 32bit
Verfasst: 04.09.2013 18:06
von Helle
Wo mit ASM rumhantiert wird bin ich nicht weit
! Leider die Zeit... Aber eine Anmerkung zu STARGÅTEs Code: Die 5.Division ist mMn überflüssig; und gerade die (Integer-) Divisionen gelten ja als Taktfresser. Also z.B.:
Code: Alles auswählen
!base85_loop:
!MOV eax, [ecx] ; Tiefer Dividend-Teil
!BSWAP eax
!MOV edx, 0 ; Hoher Dividend-Teil = 0
!DIV ebx ; Erste Division
!ADD [edi+4], dl ; Rest (nur das tiefste Byte) kommt in den String, addiert auf das "!"
!MOV edx, 0
!DIV ebx ; Zweite Division
!ADD [edi+3], dl
!MOV edx, 0
!DIV ebx ; Dritte Division
!ADD [edi+2], dl
!MOV edx, 0
!DIV ebx ; Vierte Division
!ADD [edi+1], dl
;!MOV edx, 0
;!DIV ebx ; Fünfte Division
!ADD [edi+0], al ;dl
!ADD ecx, 4 ; Leseadresse + 4
!ADD edi, 5 ; Schreibadresse + 5
!CMP ecx, [p.p_Input] ; Fertig?
!JNZ base85_loop
Ich hoffe, ich irre mich nicht!
Gruß
Helle
Re: Optimiert(est)er peek für einen unsigned long 32bit
Verfasst: 04.09.2013 18:10
von NicTheQuick
Eine Sache habt ihr übrigens übersehen in eurem ASM-Code. Wenn vier Nullbytes nacheinander kommen, dann soll nur ein 'z' geschrieben werden, also keine 5 Nullbytes.
Re: Optimiert(est)er peek für einen unsigned long 32bit
Verfasst: 04.09.2013 18:42
von STARGÅTE
Ja klar Helle, wenn ich 100 / 85 dividiere bekomme ich ja gleich beide Teile, die 65 aus dem Rest und das Ergebnis 11 ist ja gleich der andere Teil , denn 11/85 ergibt ja auch Rest 11 .
@Nic:
Meiner Meinung nach wäre das aber nur n Geschwindigkeitsbremse, wenn die vier NUL-Bytes nicht in den 4er block fallen, werden sie übersehen. Man müsste dann also Byte für Byte umwandeln, was wieder zu viel zeit kostet.
Das "z" ist ja auch nur n Verkürzung von "!!!!!", trotzdem würde ja "!!!!!" wieder richtig umgewandelt werden, wenn man decodiert.
Trotzdem ist dein Einwand natürlich richtig.