3 ms·
All of those are misleading because the FS segment override isn't specific to an operand. It applies to the whole instruction, which commonly has one place (a m
by burfog 10y ago
All of those are misleading because the FS segment override isn't specific to an operand. It applies to the whole instruction, which commonly has one place (a memory reference) for the override to take effect. You can have more than one override, but only the last one remains active. Normally you can have an override even if it isn't used. There are a few instructions with more than one memory access; the override only applies to one access and you don't get to choose which one.
- Grom_PE 10y agoNo. This is misleading: fs movs byte [edi], [esi] This is a syntax error: movs byte [fs:edi], [esi] And this is a valid override with sensible syntax: movs byte [edi], [fs:esi]
- burfog 10y agoHow would you disassemble that instruction with more than one segment prefix in front of it? The hardware accepts this by ignoring all but the final segment prefix. For example, the prefixes might be: FS, REP, GS, FS, FS Note that code can jump past some of the prefixes. The C library on Linux does this to bypass prefixes. Reasonable assembly syntax needs to be able to describe this. You need to be able to put a label right after a prefix.
- Grom_PE 10y agoIdeally, like this: fs rep gs fs ; Note: extraneous prefix mov eax, [fs:ebx] Some of disassemblers may put them as raw bytes (db 0x63, 0xf3, 0x65, 0x64). > Note that code can jump past some of the prefixes. The C library on Linux does this to bypass prefixes What's the use case for this? I wouldn't split the prefix from the instruction and would rather use label+1 where it's absolutely required.
- burfog 10y agoAn example is bypassing a LOCK prefix when there is only 1 thread or only 1 CPU.