S7 Finding first true bit in an array

[Bratt]

So these are my findings.
Each block was executed 500 times in a 315F-2PN/DP CPU 315-2FH13 0AB0

No bits First bit true Last bit true
FC44 ~19ms ~24ms ~32ms
FC45 ~33ms ~32ms ~44ms
FC99 ~525ms ~18ms ~524ms
FC100 ~78ms ~19ms ~109ms
FC101 ~30ms ~26ms ~57ms
FC102 ~30ms ~20ms ~33ms

FC044 L D[AR2,P#0.0]'s block from previous post
FC045 Same as FC44 using any pointer instead
FC099 Looping bit by bit
FC100 Loop byte by byte then bit by bit
FC101 Loop dword then word then byte then rotate bits
FC102 Loop dword then convert to float

 

[jacekd]

Great job Bratt. Thanks for your effort.

 

[Doug-P]

However, you should google for
bit hacks
bit tricks
You bit bucket will runneth over.

Nice pun!

"bit twiddling" is also productive.

 

[Peter Nachtwey]

Nice pun!

"bit twiddling" is also productive.

Yes, back in the 70's the term hacker was not a derogatory term. Hackers were experimenters. I think just about all these bit hacks were discovered BY the 70's. I know they were use used in chess programs back then that used bit boards. All competitive chess programs use bit boards so anding and oring sets of bits was common. So was trying to find the index or square that a bit represented.

It is nice that Bratt was willing to take the time to show his results. I didn't expect at 10x result because the S7 has a relatively efficient way of indexing into an array of bits. At least I thought so. Now it looks like loading 32 bits at a time is the big time saver because is reduces memory accesses. I am also surprised that using the floating point worked as well as it does. Normally this trick can only work on CPUs that have a hardware floating point processor. Does the F after 315F mean there is a hardware floating point processor?
It is obvious that Bratt will save a lot of CPU time if his program does a lot of bit index searching.

Bratt, if you like chess and computers you should look into computer chess. Computer chess was populat in northern Europe. I have got busy with other things so I lost track and am not current anymore.

 

[JesperMP]

Does the F after 315F mean there is a hardware floating point processor?

The "F" means that it is a CPU for safety applications.
Apart from that, I am certain that all the S7 CPUs have an FPU.
I know that an F CPU achieves the "dual safety technologies" by running the safety code in parallel in the main CPU and the FPU.
Apart from that, non-F and F CPUs have the same floating point instruction timing, so by logical conclusion I can say that all S7 CPUs have an FPU (maybe except for the very basic 312).

 

[Doug_Adam]

I am also surprised that using the floating point worked as well as it does. Normally this trick can only work on CPUs that have a hardware floating point processor.

About a year and a half back I did some speed tests on an old (64k memory) and new (128k, single slot width) 315-2DP CPUs.
The test was to check the scan time on each of 10,000 multiplications for integers, double integers and floating point numbers.

The interesting outcome was that for the newer CPU there was no significant speed difference between double integer and floating point multiplications, whereas for the older CPU the floating point multiplications took around twice as long as the double integer multiplications.

Looks like Siemens have added or improved their floating point co-processor about 2 years ago.

 

[Bratt]

It is obvious that Bratt will save a lot of CPU time if his program does a lot of bit index searching.

I also learned a lot

Looks like Siemens have added or improved their floating point co-processor about 2 years ago.

Interesting i'm gonna go with the floating point version then.

Thanks again everyone for your time!

 

[L D[AR2P#0.0]]

Here's an smaller quicker version of FC44 if it's not too late:

FUNCTION FC 43 : VOID
TITLE =
VERSION : 0.1

VAR_OUTPUT
  iBitOffset : INT ; 
  bFound : BOOL ; 
END_VAR
VAR_TEMP
  dwBits : DWORD ; 
  iBitNo : INT ; 
  dwData : DWORD ; 
END_VAR
BEGIN
NETWORK
TITLE =Find first bit set in 4 dwords starting at DB2.DBD0
	  LAR1  P#0.0; 
	  L	 DB2.DBD	0; 
	  OD	DW#16#0; 
	  JP	eval; 
	  +AR1  P#4.0; 
	  L	 DB2.DBD	4; 
	  OD	DW#16#0; 
	  JP	eval; 
	  +AR1  P#4.0; 
	  L	 DB2.DBD	8; 
	  OD	DW#16#0; 
	  JP	eval; 
	  +AR1  P#4.0; 
	  L	 DB2.DBD   12; 
	  OD	DW#16#0; 
	  JP	eval; 
	  JU	noev; 
eval: CAD   ; 
	  T	 #dwData; 
	  INVD  ; 
	  L	 1; 
	  +D	; 
	  L	 #dwData; 
	  AD	; 
	  T	 #dwBits; 
	  AD	DW#16#AAAAAAAA; 
	  JZ	p1; 
	  +AR1  P#0.1; 
p1:   L	 #dwBits; 
	  AD	DW#16#CCCCCCCC; 
	  JZ	p2; 
	  +AR1  P#0.2; 
p2:   L	 #dwBits; 
	  AD	DW#16#F0F0F0F0; 
	  JZ	p3; 
	  +AR1  P#0.4; 
p3:   L	 #dwBits; 
	  AD	DW#16#FF00FF00; 
	  JZ	p4; 
	  +AR1  P#1.0; 
p4:   L	 #dwBits; 
	  AD	DW#16#FFFF0000; 
	  JZ	p5; 
	  +AR1  P#2.0; 
p5:   SET   ; 
	  S	 #bFound; 
	  TAR1  ; 
	  T	 #iBitOffset; 
	  JU	Exit; 
noev: SET   ; 
	  R	 #bFound; 
Exit: SET   ; 
	  SAVE  ; 
END_FUNCTION

 

[Bratt]

Never to late for improvements, Thanks!

No bits First bit true Last bit true
FC43 ~19ms ~21ms ~29ms