Verfasst: 09.10.2008 10:40
Genau.
In einer Prozedur krieg ich das ja auch noch hin mit der Variablen, aber dann in einem Makro hab ich keine Ahnung mehr
.Seite 2 von 3
Verfasst: 09.10.2008 13:18
Wieso verwendest du zum einen Integer benutzt dann aber doch wieder long in dem asm-teil?
In einer Prozedur krieg ich das ja auch noch hin mit der Variablen, aber dann in einem Makro hab ich keine Ahnung mehr .
In einer Prozedur krieg ich das ja auch noch hin mit der Variablen, aber dann in einem Makro hab ich keine Ahnung mehr
.Verfasst: 09.10.2008 14:09
Ich habe nirgendwo explizit .l verwendet. "value" und "result" nehmen den Default-Typ an. "Procedure.i" kennzeichnet auch den Default-Typ, oder nicht?
Aber egal, wie ich schrieb ist das ganze für PB 4.20, davon gibt's eh keine 64-bit-Version. Also kann man auch "Procedure.l" schreiben.
Wie solch ein ASM-Code für 64 bit aussieht weiß ich nicht.
Ich weiß wer das bestimmt weiß, aber derjenige ist meistens nur im Urlaub fleißig.
Vor Wurfgeschossen in Deckung gehend, Little John
Aber egal, wie ich schrieb ist das ganze für PB 4.20, davon gibt's eh keine 64-bit-Version. Also kann man auch "Procedure.l" schreiben.
Wie solch ein ASM-Code für 64 bit aussieht weiß ich nicht.
Ich weiß wer das bestimmt weiß, aber derjenige ist meistens nur im Urlaub fleißig.
Vor Wurfgeschossen in Deckung gehend, Little John
Verfasst: 09.10.2008 14:29
So ungefähr müsste es aussehen in 64 bit:Little John hat geschrieben:Ich habe nirgendwo explizit .l verwendet. "value" und "result" nehmen den Default-Typ an. "Procedure.i" kennzeichnet auch den Default-Typ, oder nicht?
Aber egal, wie ich schrieb ist das ganze für PB 4.20, davon gibt's eh keine 64-bit-Version. Also kann man auch "Procedure.l" schreiben.
Wie solch ein ASM-Code für 64 bit aussieht weiß ich nicht.
Ich weiß wer das bestimmt weiß, aber derjenige ist meistens nur im Urlaub fleißig.
Vor Wurfgeschossen in Deckung gehend, Little John
Code: Alles auswählen
! mov rax, -1
! bsr rax, qword [p.v_value]
! mov qword [p.v_result], raxVerfasst: 09.10.2008 16:33
Ich ahnte doch, dass es noch einfacher geht:
Und mit einem Makro geht es z.B. so:
Ohne "EnableASM" hab ich's mit einem Makro allerdings bis jetzt nicht hinbekommen.
Gruß, Little John
Code: Alles auswählen
EnableExplicit
Procedure.i BitScanReverse (value)
; liefert die Nummer des höchsten gesetzten Bits in 'value'
! mov eax, -1
! bsr eax, dword [p.v_value]
ProcedureReturn
EndProcedure
Debug BitScanReverse(8)Code: Alles auswählen
EnableExplicit
EnableASM
Define v, res
Macro BitScanRev (value, result)
; liefert die Nummer des höchsten gesetzten Bits in 'value'
v = value
mov eax, -1
bsr eax, v
mov result, eax
EndMacro
BitScanRev(8, res)
Debug resGruß, Little John
Verfasst: 09.10.2008 16:40
Du kannst EnableASM an dem Anfang des Macros schreiben, und DisableASM
ans Ende des Macros, so hat es keinen Einfluß auf den Rest des Sources.
ans Ende des Macros, so hat es keinen Einfluß auf den Rest des Sources.
Verfasst: 09.10.2008 17:02
Gute Idee, danke!ts-soft hat geschrieben:Du kannst EnableASM an dem Anfang des Macros schreiben, und DisableASM
ans Ende des Macros, so hat es keinen Einfluß auf den Rest des Sources.
Gruß, Little John
Verfasst: 09.10.2008 18:29
So, nun ich doch noch (ohne Wurfgeschosse !), mir fehlt nur einfach der Sinn der MSB-Ermittlung für diesen Zweck. Also: DarkDragons 64-Bit-Code ist vollkommen richtig und läuft (zur allgemeinen Verwirrung kann man ja anstatt RAX mal z.B. R13 verwenden ). Wichtig erscheint mir aber im Zusammenhang mit BSR der Hinweis, das in der Literatur (z.B. "Das Assembler-Buch" von T.E. Podschun) BSR falsch beschrieben wird. Demnach wird als Ergebnis Null zurückgeliefert, wenn der 2.Operand Null (also kein Bit gesetzt) ist. Stimmt aber nicht! Das Ergebnis ist für diesen Fall undefiniert, nur das Zero-Flag wird gesetzt. Somit ist Little John´s Code mit Register-Setzen auf -1 durchaus richtig (das Register wird ja durch BSR gesetzt, wenn ...s.o.). Dies müsste aber noch ausgewertet werden. Und wenn ich das schon auswerten muss, kann ich auch vorher den 2.Operanden auf Null testen und dann im Code das Register-Setzen auf -1 einsparen.
Gruß
Helle
!), mir fehlt nur einfach der Sinn der MSB-Ermittlung für diesen Zweck. Also: DarkDragons 64-Bit-Code ist vollkommen richtig und läuft (zur allgemeinen Verwirrung kann man ja anstatt RAX mal z.B. R13 verwenden ). Wichtig erscheint mir aber im Zusammenhang mit BSR der Hinweis, das in der Literatur (z.B. "Das Assembler-Buch" von T.E. Podschun) BSR falsch beschrieben wird. Demnach wird als Ergebnis Null zurückgeliefert, wenn der 2.Operand Null (also kein Bit gesetzt) ist. Stimmt aber nicht! Das Ergebnis ist für diesen Fall undefiniert, nur das Zero-Flag wird gesetzt. Somit ist Little John´s Code mit Register-Setzen auf -1 durchaus richtig (das Register wird ja durch BSR gesetzt, wenn ...s.o.). Dies müsste aber noch ausgewertet werden. Und wenn ich das schon auswerten muss, kann ich auch vorher den 2.Operanden auf Null testen und dann im Code das Register-Setzen auf -1 einsparen.Gruß
Helle
Verfasst: 09.10.2008 21:38
Helle hat geschrieben:So, nun ich doch noch (ohne Wurfgeschosse
Das hat sich irgendwie verselbstständigt, nachdem die eigentliche Logarithmus-Frage beantwortet war.Helle hat geschrieben:mir fehlt nur einfach der Sinn der MSB-Ermittlung für diesen Zweck.
Ist das denn besser/schneller? Ich habe tatsächlich genau andersherum gedacht: Wenn ich das Register auf -1 setze, kann ich mir das Auf-Null-Testen sparen.Helle hat geschrieben:kann ich auch vorher den 2.Operanden auf Null testen und dann im Code das Register-Setzen auf -1 einsparen.
Gruß, Little John
Verfasst: 10.10.2008 07:05
Aber dann würde dein Programm mit -1 (alle Bits gesetzt) als Ergebnis weiterrechnen (das Register wird im Null-Fall nicht verändert)! Um eine Überprüfung wird man wohl nicht herumkommen, sonst wird dies eines jener Programme, wo man bei der nachträglichen Fehlersuche das Keyboard auf dem Monitor zerschlägt .
Gruß
Helle
. Gruß
Helle