shl problem

[Thaddy]

Or simply make use of the helpers from sysutils...
They have extensive bit testing/setting on most signed or unsigned integer types. (written by me and extensively expanded by Avra)
It also contains helpers for binary representation.

[MathMan]

<snip>

fwiw: Apparently x86_64 processors do not have a bittst instruction or the optimizer isn't capable of producing code with it.

TRon - it is the latter. There are

* 'BT' <= bit test
* 'BTC' <= bit test and clear
* 'BTR' <= bit test and reverse
* 'BTS' <= bit test and set

However - the majority of cases can be covered by 'TEST' and in my experience these opcodes are not produced by modern compilers (I won't even start speculating about the background), so FPC is in good company 

Cheers,
MathMan

[jamie]

Actually,

BTC: performs the Test, setting the CF flag and then does a complementary of the bit thus reversing its state after the operation.

  So this means a bit was off, it's now ON and vise versa.

I wanted to add also.

BTR is actually Bit Test and then Reverse SET. Meaning it will always clear the bit(OFF).

[jamie]

In the process of moving some code over to D, I found out I made a mistake in using intrinsic fpc functions which allow  you to work much faster for bit operations, now I am attempting to make a unit that has those those functions for D, however, this thread put a spark in me since there is one thing that seems to be a code hog when it comes to bit manipulations.

 I've tried Tbits of course and that is just simple over loaded and ok for basic stuff but does not fair well for speed.

 So I've come up with some bit functions that maybe FPC should implement as intrinsic so they better fit the ABI in use and insert into the code better.

 But here I use the Windows 64 bit ABI.

Code: Pascal  [Select][+][-]

1. unit Unit1;
2.  
3. {$mode objfpc}{$H+}
4.  
5. interface
6.  
7. uses
8.   Classes, SysUtils, Forms, Controls, Graphics, Dialogs, StdCtrls;
9.  
10. type
11.  
12.   { TForm1 }
13.  
14.   TForm1 = class(TForm)
15.     Button1: TButton;
16.     procedure Button1Click(Sender: TObject);
17.   private
18.  
19.   public
20.  
21.   end;
22.  
23. var
24.   Form1: TForm1;
25.  
26. implementation
27.  
28. {$R *.lfm}
29.  
30. { TForm1 }
31. { ABI in use is for Windows 64 bit}
32. { 32 bit would need to use the proper registers}
33. { Set Bit and return state of before}
34. Function BITSET(Const Abase:Byte;Var aValue):Boolean;Assembler; NoStackFrame;
35.   Asm
36.    BTSQ %CX,(%RDX);
37.    SETC %AL;
38.   end;
39. {Clear bit and return state before}
40. Function BITCLR(Const Abase:Byte;Var aValue):Boolean;Assembler; NoStackFrame;
41.   Asm
42.    BTRQ %CX,(%RDX);
43.    SETC %AL;
44.   end;
45. {Complement and return state of before}
46. Function BITCPT(Const Abase:Byte;Var aValue):Boolean;Assembler; NoStackFrame;
47.   Asm
48.    BTCQ %CX,(%RDX);
49.    SETC %AL;
50.   end;
51. procedure TForm1.Button1Click(Sender: TObject);
52. Var
53.   I:LongWord;
54. begin
55.   I:= 1;
56.   Caption := BITCLR(0,I).ToString+','+I.ToString; //Etc.
57. end;
58.  
59. end.
60.  
61.  

ignore the typeless parameter, I do that all the time, it saves on code and its for real men! 

if you feel a little nervous about using it, then make some OVERLOADed versions of it.

If implemented along with the other BIT functions that already exist in the FPC, they can then take care of that part.

[MathMan]

Actually,

BTC: performs the Test, setting the CF flag and then does a complementary of the bit thus reversing its state after the operation.

  So this means a bit was off, it's now ON and vise versa.

I wanted to add also.

BTR is actually Bit Test and then Reverse SET. Meaning it will always clear the bit(OFF).

jamie,

Thanks for noting and clarifying - I wrote in a haste 

[MathMan]

In the process of moving some code over to D, I found out I made a mistake in using intrinsic fpc functions which allow  you to work much faster for bit operations, now I am attempting to make a unit that has those those functions for D, however, this thread put a spark in me since there is one thing that seems to be a code hog when it comes to bit manipulations.

<snip>

Nicely done, but be aware of the restrictions that are associated with the bit field ops on memory! I usually go here - https://www.felixcloutier.com/x86/ - if I do quick checks and there is a very specific statement, that

"... It may do so even when only a single byte needs to be accessed to reach the given bit. When using this bit addressing mechanism, software should avoid referencing areas of memory close to address space holes. In particular, it should avoid references to memory-mapped I/O registers. Instead, software should use the MOV instructions to load from or store to these addresses, and use the register form of these instructions to manipulate the data ..."

The above might get obscured by a generic intrinsic. But if you know what you're doing then your implementation will help on large bitfield operations. I used it once for a fast sieve of Erathostenes implementation.

Cheers,
MathMan

[TRon]

Thank you @mathman and @jamie.

Shortly after my post I founf that there is indeed a x86 bittest instruction and figured it isn't generated by the compiler/optimizer and thus was going the same route as jamie showed.

As detailed by jamie some of these special instructions (re)set a bit when using the corresponding mnemonic (though it was clear for me from mathman's post and reading the explanations).