addressing-mode

问题 I noticed that in Assembly segments are used in opcodes. Example: MOV DWORD PTR SS:[EBP-30],30 I think that "PTR SS:" is used to specify that EBP-30 comes from the stack? (SS: stack segment) Am I right or am I completely wrong? :) And, could you please tell me the difference between the example above and MOV DWORD PTR[EBP-30],30 And what about DS (data segment) used in opcodes? 回答1: MOV DWORD PTR SS:[EBP-30],30 There are two separate modifiers here, DWORD PTR and SS: . The first one tells us

问题 Does rax get offset plus the address of this instruction, or the next? From a microcode point of view it might be easier if the answer was the next instruction. 回答1: The next. That's a general rule on x86 (see also branches). In Intel's manual volume 2 section 2.2.1.6 RIP-Relative Addressing: A new addressing form, RIP-relative (relative instruction-pointer) addressing, is implemented in 64-bit mode. An effective address is formed by adding displacement to the 64-bit RIP of the next

问题 The movsb (move string, bytes) instruction fetches the byte at address ds:si, stores it at address es:di, and then increments or decrements the si and di registers by one. I know esi,si and edi,di registers, but not ds:si and es:di , what do they mean? 回答1: ds:si and es:di mean the segment:offset referred to by the registers in question. This is primarily important when you're working in real mode (where offsets are a maximum of 64K apiece). In real mode, the segment are offset are combined

问题 I'm currently trying to write a disassembler. I found the following list of opcodes and their meanings, so i decided to parse it at runtime: http://mprolab.teipir.gr/vivlio80X86/pentium.txt But i am stuck at the opcode 0x00: It is followed by a reg/modbyte. Parsing it was not much of a problem for me. But I'm having trouble with the Scale-Index-Base byte: If you actually specify esp as index register, it actually means that there is no index register. The same applies for the base register

问题 I've been working through a project book as an introduction to MIPS and I've come across a problem. One of the lines of code in the book is lb $t3, ($t2) . I have no clue what the parentheses do because prior to this, I haven't seen them used, and the book just doesn't mention them to begin with. Why wouldn't the code just be lb $t3, $t2 ? 回答1: MIPS addressing-mode syntax is constant($reg) . ($t2) is allowed as a special case short-hand for 0($t2) . The same instruction could do lb $t3, 13(

问题 I'm trying to figure out whether the following piece of assembly code is invalid. movb $0xF, (%bl) Is it invalid? If so, why? Thanks. 回答1: You don't say what processor. bl is a 8-bit register at least in x86 processors, but it cannot be used for addressing. Why is it invalid instruction? Well, the reason an assembly instruction is invalid is that there's no such instruction for the given processor. There is no possible way to encode this instruction. In this case (assuming x86), using bl or

问题 I'm trying to figure out whether the following piece of assembly code is invalid. movb $0xF, (%bl) Is it invalid? If so, why? Thanks. 回答1: You don't say what processor. bl is a 8-bit register at least in x86 processors, but it cannot be used for addressing. Why is it invalid instruction? Well, the reason an assembly instruction is invalid is that there's no such instruction for the given processor. There is no possible way to encode this instruction. In this case (assuming x86), using bl or

问题 I'm trying to figure out a reason for the scale factor not being present in the x86 16-bit addressing modes (MASM assembly). While the 32-bit and 64-bit addressing modes have a scale factor. Is there an actual reasoning behind this or it doesn't need it? I would appreciate it if you could explain. All possible ways different components can be combined to create an effective address: Differences between 16- and 32-bit addressing modes 回答1: 16-bit addressing modes only allow a single ModRM byte

问题 I am using a CUDA texture in border addressing mode ( cudaAddressModeBorder ). I am reading texture coordinates using tex2D<float>() . When the texture coordinates fall outside the texture, tex2D<float>() returns 0 . How can I change this returned border value from 0 to something else? I could check the texture coordinate manually and set the border value myself. I was wondering if there was CUDA API where I can set such a border value. 回答1: As mentioned by sgarizvi, CUDA supports only four,

问题 in Assembly Addressing (64-bit), which way is better? mov cl, BYTE [ebx + .DATA] or mov cl, BYTE [rbx + .DATA] ? the opcode for first way is : 67 8a 4b .. and the opcode for second way is : 8a 4b .. so if we use 32-bit register, we need to have a '0x67' prefix (Address-size override prefix) so i think we added an extra job !!! but i heard something about (CACHE) and it's better to use '32-bit' instead of '64-bit' so which way is better at all ? and why ? 回答1: TL:DR: you basically never want