Reversing bit order in delphi ? (unmoderated)
in [ASM]
|
Prev: Apple II Debugger
Next: TMA Assembler?
From: Phil Bostock on 26 Aug 2006 07:32 Dunny wrote: > In news:wRMHg.725$Gb2.526(a)newsfe03.lga, > Jamie <jamie_ka1lpa_not_valid_after_ka1lpa_(a)charter.net> typed: > >> Skybuck wrote: > >>> "I am glad I never hired Jamie to code my airoplanes :P ;)" > >> i wouldn't worry about that, at this point you wouldn't be >> able to start a business let alone hold one. >> go back to your books. i think you missed a chapter. > > Well, I would say that we're all very glad that Skybuck doesn't write > dictionaries :-) > > D. > > I'm glad that he doesn't work in the State Department, or the Pentagon. Phil
From: f0dder on 26 Aug 2006 13:24 Jim Carlock wrote: > Jim Carlock wrote: >> *snip* > > "f0dder" <f0dder.nospam(a)flork.dk.invalid> wrote: >> The OR method is somewhat cute, but won't it have a zillion >> mispredicted performance killing branches? :) > > Performance killing branches? I'm not sure I follow where you > want to go. The BT/JNC/OR sequence... lots of conditional branches there.
From: Skybuck on 26 Aug 2006 18:12 f0dder schreef: > Jim Carlock wrote: > > > *snip* > > The OR method is somewhat cute, but won't it have a zillion mispredicted > performance killing branches? :) Why would it mispredict ? Bye, Skybuck.
From: Skybuck on 26 Aug 2006 18:20 Jim Carlock schreef: > Skybuck wrote some stuff about times: > > > "f0dder" <f0dder.nospam(a)flork.dk.invalid> wrote: > > *snip* > > You use some pretty nonstandard way of measuring performance. > > The normal is to decide a number of times to call each routine, > > then measure how long it takes (usually in clock cycles, though > > miliseconds is okay for a large number of calls). > > Did he actually post his timing algorithm? I agree, normally bigger > numbers indicate greater amounts of time taken. > > Another method involves ORing instead of BTSing... > > xor edx, edx ; edx is used as result variable > BT eax, 7 ; test bit 7 > > jnc skip7 ; if bit 7 = 0 goto skip7, else set bit0 = 1 > OR EDX, 1 > skip7: Thanks for this method. I forgot "or" and "and" can be used to manipulate bits as well even single ones ;) Here are another few variations of the same code/idea: "The "mov" and "and" and "jnz" method:" xor edx, edx mov ecx, eax mov al, cl and al, 128 jnz @skip7 // jnp could be used as well ;) or maybe jp not sure ;) or dl, 1 @skip7: mov al, cl and al, 64 jnz @skip6 // jnp could be used as well ;) or maybe jp not sure ;) or dl, 2 @skip6: etc. "The "test" and "jnz" method:" The "mov" and "and" instructions can be replaced with a "test" instruction. This also removes the need to use an additional register (ecx). xor edx, edx test al, 128 jnz @skip7 or dl, 1 @skip7: test al, 64 jnz @skip6 or dl, 2 @skip6: etc The remarkable thing is that the BT and BTS method is actually slighty faster ! ;) Bye, Skybuck.
From: Skybuck on 26 Aug 2006 18:24
> If you are going to be using BT, then don't use that Carry Flag to > determine your route through the conditional jumps. CF is going to > vary wildly, but we can find other ways to put it to use: Why would CF very wildy ? I can think of a couple of reasons: 1. Multi threading might interrupt the code flow and modify the cf flag. 2. Interrupts might interrupt the code flow and modify the cf flag. 3. The method could be called from another method which was working on the cf flag. My guess would be reason 1 is not valid since os-writers are probably smart enough to push the flags on context switch. Reason 2 probably does the same ? Reason 3 might be good... So far it seems working ok. What did you mean with CF might very wildly ? Bye, Skybuck. |