Index
> Main > pop qword [rdi+rsp] |
| Author |
|
|
LocoDelAssembly
Does "pop qword [ds:rdi+rsp]" work? As for fasm compiling exactly the same for "rdi+rsp" and "rsp+rdi", that is because (besides fasm's algebra engine does not strictly follow your ordering), there is no encoding for RSP as index (or is it??)
When you tested your second code, did you make sure the direction flag was cleared? Can't see other sources of differences between the first and second codes. |
|||
17 May 2011, 05:59 |
|
|
BAiC
you obviously have my question wrong in your mind.
I didn't need the ds note, I had already expressed that issue in my original post. Quote: while the pointers obviously differ in Segments (one is the stack whilst the other is DS) the second code snippet worked, so the Direction Flag issue is moot. |
|||
|
17 May 2011, 14:20 |
|
|
typedef
Don't you have to increment or decrement rdi?
|
|||
|
17 May 2011, 15:23 |
|
|
MazeGen
BAiC, the problem might be that POP with RSP base computes the effective address of the operand after it increments the RSP register. (Weird but true, PUSH and POP with rSP base is tricky).
|
|||
|
17 May 2011, 18:16 |
|
|
LocoDelAssembly
Quote:
Quote:
Anyway, the problem probably it is what MazeGen says, I just assumed the processor always respects the RSP value prior to incrementing/decrementing it, but seems that things are different when using for addressing (even PUSH and POP handle the situation differently) Intel's PUSH documentation wrote: The PUSH ESP instruction pushes the value of the ESP register as it existed before the instruction was executed. Thus if a PUSH instruction uses a memory operand in which the ESP register is used for computing the operand address, the address of the operand is computed before the ESP register is decremented. Intel's POP documentation wrote: If the ESP register is used as a base register for addressing a destination operand in memory, the POP instruction computes the effective address of the operand after it increments the ESP register. |
|||
|
17 May 2011, 19:36 |
|
|
BAiC
typedef wrote: Don't you have to increment or decrement rdi? RSP is being incremented.. it's a bit complicated (this is a somewhat advanced topic in general): the negative RSP (sub rdi, rsp) that is stored in RDI (constant within the loop) causes only the very first RSP to be dropped from the sum leaving the multiple of 8 that gets added to RSP during each iteration of the loop. MazeGen wrote: BAiC, the problem might be that POP with RSP base computes the effective address of the operand after it increments the RSP register. (Weird but true, PUSH and POP with rSP base is tricky). not "might".. this is it. Thanks MazeGen. LocoDelAssembly wrote: Since originally you posted this into Compiler Internals as if this were a fasm's bug, I had to make the comment just in case... I posted it to Compiler Internals because at the time the possibility of Operand Override prefixes, Segment Selector prefixes, and general Instruction Encoding was running through my head as possible causes. There is no section that deals with actual encodings more specifically than Compiler Internals. LocoDelAssembly wrote: Not if RDI is pointing to the end of the buffer where obviously it would have a big advantage having DF=1 over your first code. In the pop-block the Direction Flag is irrelevant. As for the stosq code, what you're referring to would require changing the code that generates the stack data: the data that is placed into rax courtesy of the "pop rax" must be sent to "low" memory which is increasing. using DF=1 would place the data into memory backwards. |
|||
|
18 May 2011, 08:54 |
|
|
LocoDelAssembly
BAiC, first of all, I apologize for the DS confusion, I had my mind a little bit biased about what you meant because of the [EBP+EBP] Vs. [EBP*2] problem in which fasm always picks the encoding of the former even though they use SS and DS respectively.
About the second code, yes, having DF=1 would reverse the data in your code, but if RDI would be at the end of the buffer it would still explain why STOSQ works while POP mem faults (e.g. in the case when the POP code fails after very few or zero iterations as opposed to your real problem which must be failing in the last iteration). Without knowing what MazeGen posted, and not being able to spot any error in both codes, I just tried to find other explanations of why your second code didn't fault (even if them break your memory copy needs) |
|||
|
18 May 2011, 17:42 |
|
< Last Thread | Next Thread > |
Forum Rules:
|