Based Indexed Addressing Mode Memory Sum

I have a instruction: ADD [BX][SI] + 5FFDH, EABFH and I want to know how it operates exactly on 8086 microprocessors. I've realized that this instruction ADD [BX][SI] + 5FFDH, EABFH, works in this manner:

1. 2 bytes of data arrive from data bus and go to instruction queue.
2. Data that available on instruction queue goes to instruction decoder.
3. Another 2 bytes of data arrive from data bus and go to instruction queue.
4. BX and SI values go to ALU and calculates BX + SI
5. Another 2 bytes of data arrive from data bus and go to instruction queue.
6. BX + SI goes to ALU's input.
7. 5FFDH pop from instruction queue and goes to ALU's input.
8. ALU calculates BX + SI + 5FFDH.
9. BX + SI + 5FFDH goes to memory through address bus.
10. BX + SI + 5FFDH's value comes from memory and goes to ALU's input.
11. EABFH pop from instruction queue and goes to ALU's input.
12. [BX + SI + 5FFDH] + EABFH calculates by ALU.
13. ???????????

So my question is on step 13. How microprocessor knows that memory address (BX + SI + 5FFDH) to send [BX + SI + 5FFDH] + EABFH's value to memory according to empty instruction queue and we cannot calculate BX + SI + 5FFDH again.

8086 almost certainly has some internal tmp storage that its microcode can use to store the result of address calculation for RMW instructions. It's not exactly pipelined the way MIPS was! (But IIRC, you're right that it used the ALU for address calculation, not having a dedicated AGU).

In theory nothing's stopping it from re-calculating the address, but keeping around the address is much more sensible than keeping around the original instruction bytes.

Keep in mind that 8086 was driven by microcode, kind of like an interpreter that implements x86 using its internal resources. So the temporary storage would just be like a register other than the architectural registers that are visible to 8086 instructions.

In this case, one might imagine that there was some circuitry for data accesses to send addresses to the bus interface unit, competing with code-fetch. It's totally plausible that some address register in the data side of things could simply hold the last data address that was used, even if code-fetch reads from a different address in between.

If you're really curious about full details, see if http://www.righto.com/2020/08/reverse-engineering-8086s.html (Ken Shirriff's blog) has gotten to how microcode handles memory-destination ALU instructions.

BTW, you forgot the DS segment-base address as part of the address calculation.