Reversing bit order in delphi ? (unmoderated)
in [ASM]
|
Prev: Apple II Debugger
Next: TMA Assembler?
From: Skybuck on 19 Aug 2006 15:31 Evenbit schreef: > Skybuck wrote: > > So what would be the fastest way in pure delphi code to reverse the > > bits ? > > > > Well, first, minimize the number of times you actually need to run > through the complete algo. Check the input to see if the bit-pattern > is symetrical or not. If it is symetrical, then you don't need to flip > it. Examples: > > 11111111 > 00000000 > 11000011 > 00111100 > 00011000 > 11100111 > 10100101 > > etc.... > > Nathan. Dude, Come back when you have a real/workable algorithm/idea ! ;) This idea of yours is only half of an algorithm/solution ! ;) Where's the rest ?!!!! =D Bye, Skybuck.
From: Skybuck on 19 Aug 2006 15:34 alanglloyd(a)aol.com schreef: > Skybuck wrote: > <snip> > > > > Reversing bit order in delphi ? > > > <snip> > > So what would be the fastest way in pure delphi code to reverse the > > bits ? > > > <snip> > > Two solution - Delphi (checked) & Delphi assembler (un-tested) ... > > type > T32BitInt = 0..31; > T32BitIntSet = set of T32BitInt; > > function SwapBits(InInteger : integer) : integer; > var > I : T32BitInt; > InBits, OutBits : T32BitIntSet; > const > RevArray : array[T32BitInt] of T32BitInt > = (31, 30, 29, 28, 27, 26, 25, 24, 23, 22, 21, 20, 19, 18, 17, 16, > 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0); > begin > InBits := T32BitIntSet(InInteger); > OutBits := []; > for I := 0 to 31 do > if I in InBits then > Include(OutBits, RevArray[I]); > Result := integer(OutBits); > end; > > function Reversed(source: longint): longint; > {it left-shifts each bit from EDX into the carry flag and then > right-shifts > the carry flag into EAX a total of 32 times (controlled by ECX)} > asm > mov EDX, EAX > mov ECX, 32 > @@AGAIN: > rcl EDX,1 > rcr EAX,1 > loop @@AGAIN > end; > > It would be interesting to know the relative speeds. See the other posting ;) Your Reversed function needs a little bit of fixing when it comes to bytes only. Can you fix your basm function so it doesn't need the wrapper / the shr 24 ? Try re-entering the competition with faster implementations which work on a single byte only ! ;) =D You last man ! =D All in all not too shabby you did pretty good, just not fast that's all ;) Bye, Skybuck ;)
From: Skybuck on 19 Aug 2006 15:36 > ; assumes byte to reverse in al > ; trashes ah, ecx, flags > > mov ah, al > mov ecx, 8 > top: > rcr ah, 1 > rcl al, 1 > sub ecx, 1 > jnz top > > That wouldn't be particularly fast, but I think it'll do what you want. Congratulations to you ! You ended up 3st place so far ;) ! =D And the best part is your code worked straight out of the box.. well almost... just had to change a label to delphi style: In delphi labels should start with @ or @@ or @@@@@@@@@ :) I forgot about that as well, thankfully Alan's example showed how to do it ;) peeeep. Bye, Skybuck.
From: Skybuck on 19 Aug 2006 15:38 > xlat. > At the cost of a 256-byte table, it is easiest and fastest to just look the > byte up. It even used to be a well-known trick (you can mirror bitmap images > this way). > As a side note I might add that though 'xlat' *is* a special instruction for > table lookup, it's usually faster (!) to use the regular memory read > functions. (That's from hear-say!) > > [Jongware] Euhm can you provide some assembler code ? Then maybe I can enter you into the competition ! ;) Bye, Skybuck.
From: Evenbit on 19 Aug 2006 15:53
Skybuck wrote: > Herbert Kleebauer schreef: > > If it real is just a byte, why not use a 256 byte lookup table (xlat)? > > And if there are more bytes, swap the bytes (if necessary) and use > > for each byte the lookup table. > > Wow such a simple and great idea ! Good thinking dude ! Easy to > implement too ! > > However I must ask some question in the light of speed. > > A lookup table requires a memory access and some pointer/memory > calculations.. that's about it probably. > > Suppose 2000 "data" bytes needs to be reversed... what will happen with > the lookup table and what will happen with the "data" bytes. > > I am not sure how CPU's work... but it would be good if the data bytes > and lookup table end up in the cpu's cache... otherwise the memory > access might slow things down. > > Alternative is too not use a lookup table and only instructions and > data... > > Gje I wonder what would be faster, I have no idea. > > I shall benchmark both ideas. > > Great ! > Wow! Did you even take a look at XLAT before typing that response??? Nathan. |