int add(int a, int b) {
    return a + b;
}
    

add:
        lea     eax, [esi+edi]
        ret
    

lea eax,[esi+edi]    

eci:
...
lea eax,[eci+edi]    

lea eax,[esi+edi]
    

Should also note here that such a procedure might not give any performance gain since the overhead of calling a procedure plus depending on these particular registers might be greater than the possible gain. Even with modern optimizing hardware I really doubt you’ll even notice any gain, and I’d even bet that you’ll see performance loss when measured.

The problem was that the value I sent to the esi and edi registers did not match the size of the registers and the operands (since a variable was actually pointed to in memory).

Really? However GCC (which is not just any compiler) optimizes this operation with this code though... What would be the best way to optimize this type of procedure in your opinion?

Or optimizes addition of two values in registers with this particular instruction? Then what made you think it would be faster in a non-inline manner?

add eax,esi,edi ;<--- lea eax,[esi+edi]    

DimonSoft wrote:

Or optimizes addition of two values in registers with this particular instruction? Then what made you think it would be faster in a non-inline manner?

Oh, I don't know, I probably would have done it in two separate instructions, but this "optimization", it was GCC that gave it.

for (int i = 0; i < N; ++i)
  ...    

void RealIncrement(int **ppInt)
{
  ++(**ppInt);
}

void Increment(int *pInt)
{
  RealIncrement(&pInt);
}

i = 0;
while (i < N)
{
  ...
  Increment(&i);
}    

LEA is a badly named instruction IMO.

It leaks the implementation details of the original 8086 CPU. Great if you are a CPU design engineer. Terrible if you are an assembly programmer.

Better would be a three operand ADD instruction.

Code:

add eax,esi,edi ;<--- lea eax,[esi+edi]    

But with the difference that the flags register is not updated when compared to the normal two operand ADD.

You say you don’t know but in the same sentence you say GCC gave it to you. So, I guess, you took a look at the disassembly of what GCC had generated.

DimonSoft wrote:

You say you don’t know but in the same sentence you say GCC gave it to you. So, I guess, you took a look at the disassembly of what GCC had generated.

Yes, indeed, but by that I meant I don't know if it's a "real" optimization from what you seem to be saying.

All I'm trying to do is give the best assembler code possible for my compiler (which I'm creating), and while I'm at it, try to optimize it to the maximum.

Really? However GCC (which is not just any compiler) optimizes this operation with this code though... What would be the best way to optimize this type of procedure in your opinion?

LEA is a badly named instruction IMO.

It leaks the implementation details of the original 8086 CPU. Great if you are a CPU design engineer. Terrible if you are an assembly programmer.

Better would be a three operand ADD instruction.

Code:

add eax,esi,edi ;<--- lea eax,[esi+edi]    

But with the difference that the flags register is not updated when compared to the normal two operand ADD.

revolution wrote:

LEA is a badly named instruction IMO.

It leaks the implementation details of the original 8086 CPU. Great if you are a CPU design engineer. Terrible if you are an assembly programmer.

Better would be a three operand ADD instruction.

Code:

add eax,esi,edi ;<--- lea eax,[esi+edi]    

But with the difference that the flags register is not updated when compared to the normal two operand ADD.

But that would require changes in machine code format for this instruction and, probably, for other instructions as well. And it might not be 8086, it might be one of its predecessors. Say, BX in 8086 is said to be made up of two registers (H and L) in 8080: Why does the x86 have so few registers?. And certain backward compatibility might also be the case with the number of operands.

revolution wrote:

LEA is a badly named instruction IMO.

It leaks the implementation details of the original 8086 CPU. Great if you are a CPU design engineer. Terrible if you are an assembly programmer.

Better would be a three operand ADD instruction.

Code:

add eax,esi,edi ;<--- lea eax,[esi+edi]    

But with the difference that the flags register is not updated when compared to the normal two operand ADD.

Nah, even ignoring 16-bit addressing (which has more limitations), you also have scale so add eax,esi,edi*4 and so on would have to work. And esp can't be used as index. etc.

Same rules as memory addressing so lea is ok.

Fair enough. Then we can change ADD to COMPUTE, or whatever. But using LEA with the brackets is not the best way to do it IMO.

revolution wrote:

Fair enough. Then we can change ADD to COMPUTE, or whatever. But using LEA with the brackets is not the best way to do it IMO.

You are probably not a fan of what they did with MPX then?

Tomasz Grysztar wrote:

revolution wrote:

Fair enough. Then we can change ADD to COMPUTE, or whatever. But using LEA with the brackets is not the best way to do it IMO.

You are probably not a fan of what they did with MPX then?

I'm actually mostly okay with that because the values used are genuinely addresses with no other purpose. No computation is involved.

I still don’t get: has GCC really generated a separate procedure with a single LEA instruction?

DimonSoft wrote:

I still don’t get: has GCC really generated a separate procedure with a single LEA instruction?

Yes, look here