+ vs |

[Kennedy]

Performing a code review. I believe that + will actually be slower than | in this case, but I want a second, third. . . etc opinion:

unsigned short status;
unsigned char LSB, MSB;

LSB = <some value, but we don't care>;
MSB = <some other value, be we still don't care>;
status = ((MSB & 0xff) << 8) + (LSB & 0xff);

OR

unsigned short status;
unsigned char LSB, MSB;

LSB = <some value, but we don't care>;
MSB = <some other value, be we still don't care>;
status = ((MSB & 0xff) << 8) | (LSB & 0xff);

Which one of these will be faster (keeping in mind that the cross-compiler that is being used doesn't do _ANY_ optimization -- it is a compiler for the TI2808 DSP).

Thanks for your input,
Andy

[matsp]

In this case, it won't make any difference. Of course, it's a case of "semantically correct" and "semantically incorrect". Addition is indeed giving the same result, but you do not really want to ADD numbers together, do you. You want to merge two bytes into a single 16-bit word. So OR is the operator is the logically and semantically correct thing to do.

Telling the compiler what you mean MAY give it a better option to produce good code, and it certainly gives the reader the right message.

There are situations where + and | are not replacable:

int x = 0;
...
if (y) x |= 8;
....
if (z) x |= 8;
...
if (x & 8) ...

The above code will obviously not work if you use +, since if both y and z are true, the value in x is 16, not 8 as we would expect from this particular piece of code. #

Edit: Oh, as to which is faster: that really depends on the processor, and the actual instructions the compiler generates for each option. In most processors, OR and ADD would be equivalent timing-wise. But in a less common variant of processor, the designer may have decided to not implement an OR instruction, so the OR has to be done using a combination of NOT and AND operations, which would of course be slower. Or, in a very extreme case, ADD may have been omitted, and you have to ADD by using a combination of AND, OR, NOT, etc. That's very unlikely.

Is this really in a time-critical part of the code?

--
Mats

[Kennedy]

Readability does go through the floor in this case. . . but I won't ding him for readability as my code is not always readable. I'm trying to dig deep to the attic of my brain and remember how the + vs | operators are actually played out on the processor. I'm thinking that | would be way faster anyway (by four or five instructions). Am I right?

[slingerland3g]

Lol, what matsp said. My first thought was that there really is no difference but really there is if you want your code to somewhat be more meaningful and what the intent.

[matsp]

I was trying to find out, but unfortunately, it seems like TI's website is extremely slow.

I have really no idea myself. I guess you could look at the assembler produced by the compiler.

--
Mats

[Kennedy]

True that, I don't have the compiler (and I'm stepping on toes here). . . so, I probably won't be able to see the assembly behind it.

I was trying to find out, but unfortunately, it seems like TI's website is extremely slow.

Not only that, but I don't think they have the support docs anymore. The 2808 was sold to someone else (from what I've been told -- but I don't know). I couldn't even find the alleged programming docs for it.

Andy

[iMalc]

I don't think it matters whether your guess that | is faster then + matters here. | more correctly indicates the intent. Also I would use the simpler operation when given the choice.

If you think it warrants a mention during code review then go ahead and mention it. I personally might mention it but wouldn't insist on changing it.

It's similiar to if they had used *256 instead of <<8, and in that case I would certainly speak up. Actually for that matter it could be <<CHAR_BIT anyway .

[quzah]

This is an odd thread. You do know that OR and ADD aren't the same operation right?

1 + 2
1 | 2

Both of those just HAPPEN to be the same. However...

2 + 2
2 | 2

Not the same.


Quzah.

[slingerland3g]

This is an odd thread. You do know that OR and ADD aren't the same operation right?

1 + 2
1 | 2

Both of those just HAPPEN to be the same. However...

2 + 2
2 | 2

Not the same.


Quzah.

That is true, as you are really concerned with those bit positions' values when using bitwise operators. But this is an odd discussion but interesting none the less as this brings up a nice little side discussion on good programming practices and leads to self documenting code.

[nonoob]

ADD and OR machine instructions have equivalent timing on anything since minis back in the mid 70s. These instructions have long since been implemented in hardware (gates and such rather than microcode), so that their execution is done in 1 clock. All the way up through 8-bit Zilog's Z80 and Motorola 6800, and all throughout the Intel family.

You can't get better than 1 clock - or can you? With parallel pipelining you can achieve sub clock speeds in effect. But integer simple operations are among the most fundamental that processors do natively.

So, I realize there are many here that like to opine without providing examples and counter-examples, and ultimately providing no additional useful information, but I vote that the two operations are equivalent.

[Kennedy]

This is an odd thread. You do know that OR and ADD aren't the same operation right?

1 + 2
1 | 2

Both of those just HAPPEN to be the same. However...

2 + 2
2 | 2

Not the same.


Quzah.

The first post I made was the case that was of interest here. . . the original question was is it faster to add two bytes together (one shifted to the left 8 bits) or to bitwise OR them together. I'm still leaning towards bitwise OR, though I still cannot look at the assembly that it compiles down to -- btw, this compiler does not make object files, but asm files that are then run through the TI2808 assembler. For what it is worth.

[itCbitC]

The first post I made was the case that was of interest here. . . the original question was is it faster to add two bytes together (one shifted to the left 8 bits) or to bitwise OR them together. I'm still leaning towards bitwise OR, though I still cannot look at the assembly that it compiles down to -- btw, this compiler does not make object files, but asm files that are then run through the TI2808 assembler. For what it is worth.

Find out if the compiler can be forced to stop after generating the asm files instead of automatically invoking the assembler. This way you can look at the underlying assembler code and figure out if logical addition "|" is faster than arithmetic addition "+".

[Kennedy]

Find out if the compiler can be forced to stop after generating the asm files instead of automatically invoking the assembler. This way you can look at the underlying assembler code and figure out if logical addition "|" is faster than arithmetic addition "+".

See Post #6. The compiler leaves the asm files, but I cannot see them.

[matsp]

ADD and OR machine instructions have equivalent timing on anything since minis back in the mid 70s. These instructions have long since been implemented in hardware (gates and such rather than microcode), so that their execution is done in 1 clock. All the way up through 8-bit Zilog's Z80 and Motorola 6800, and all throughout the Intel family.

And you KNOW that the TMS320C2808 processor does indeed have equal instruction timing for these two instructions, or are you guessing just like everyone else? I still can't get the 4MB data-sheet from focus.ti.com that I hope will get me the info (every time I try, I have to kill either FireFox or Acrobat reader).

I don't think you are wrong as such, but you are yourself saying that a lot of people have opinions. Now if you KNOW it is so for this particular processor, then fine. But if not, you are in turn just offering your opinion.

--
Mats

[nonoob]

I get your point, matsp. I overlooked that Kennedy had given the processor type - and who knows, it may be the one and only obscure one where there is a difference.