IF BIT x SET timing question


New Member
Just a quick, but probably tricky question to answer, regarding the difference in the timing length between a couple of commands - this on a 40X2 at setfreq M16. I note timing for the command
 IF var BIT value SET THEN
has not been described in the Program size Optimization and Speed document of some years ago.

I'm needing to find any speed benefits in a program and was wondering what the timing difference might be between ....

b1 = INCOMINGBYTE & %00000001
b2 = INCOMINGBYTE & %00000010
b3 = INCOMINGBYTE & %00000100
b4 = INCOMINGBYTE & %00001000
.... other code ....
IF b4 = 8 THEN MAIN ;(or some other code)
when compared to ....

(this then excludes the need to separately extract the bit value elsewhere as in the first example). INCOMINGBYTE is received over i2c from an 18M2.

Each "if bxx = " command is used only twice (maybe thrice) throughout the program but each "bit" of the incoming byte is extracted for different purposes within its own routine, but how does it compare with the second example, timing-wise, taking into account the timing of the extraction command used in the first example?

I guess the time difference would be quite minimal, but any option to speed the program, however slight, would be an advantage.

Conversely, when compiling the separate conditions into the incoming byte to be sent over i2c - on an 18M2 - are there any more speed efficient methods than using....

b0=0                                                       ; reset value
if setting1=1 then : b0=1 : endif            ; no 'setbit' command for 18M2
if setting2=1 then : b0=b0+2 : endif
if setting3=1 then : b0=b0+4 : endif
if setting4=1 then : b0=b0+8 : endif
Or would it be more overall speed efficient to send each variable separately over i2c and do away with extracting or testing for a bit value at the receive end, as per the first part of the question?



Senior Member
There are several factors that affect the time it takes to perform tasks with a PICAXE. When even a few microseconds are critical, perhaps the hardest one to resolve is caused by the way the way the program "tokens" are packed. From memory, the X2 tokens are 6-bits in size, so can fit into one byte or span across two bytes. A single command may span several tokens, so the location of each token can affect the unpacking speed, and consequently the execution speed, of a command.

There are a couple of ways to mitigate this problem.

One, which you mention, is to read a whole port into a byte. Depending on your design, you may need to read multiple ports to get the inputs of interest. The port data, saved in variables can then be processed at your leisure, although this may take longer than you want.

My recommendation would be to use a second option, that of including a 16MHz resonator and running the X2 chip at 64 MHz - that's 4 times the execution speed!


Technical Support
Staff member
Not quite sure what the speed difference would be between masking and testing the result and using IF-BIT but the fastest option would probably be to ensure your variable is 'b0' to 'b3', 'w0' or 'w1', and then use the 'bit0' through 'bit31' variables which will represent the various bits put in those.

For example all these will jump to 'Main' if bit 3 of 'b0' is set ...
b9 = b0 & %00001000
If b9 <> 0 Then Main
If b0 BIT 3 SET Then Main
If bit3 = 1 Then Main
You can similarly use the 'bit' variables to set byte or word values ...
b0 = 0
bit0 = setting1 ; 1
bit1 = setting2 ; 2
bit2 = setting3 ; 4
bit3 = setting4 ; 8
At the end of that 'b0' will automatically contain the 0 to 15 value the 'setting' variables specify.

It is IMO good practice to keep 'b0', 'b1' and 'w0' reserved as temporary variables so you can move other variables into them to utilise the 'bit' variables, 'b2', 'b3' and 'w1' if you need to do a lot of bit manipulation.

You can name things via SYMBOL which can then make things very easy to use, for example ...
Symbol status       = b0
Symbol status.error = bit7

SerIn C.0, N2400, status
If status.error = 1 Then ....
Last edited:


Senior Member

A good clue to command execution timings is often the number of program bytes created by the instructions, as reported by the Verify option. Some are effectively only "Macros" created by the PE.

Cheers, Alan.