On 10/23/10 01:04, Gabe Black wrote: > On 10/23/10 00:56, Gabe Black wrote: >> On 10/22/10 21:23, nathan binkert wrote: >>>> What do you mean by "given a certain prefix"? X86's encoding is fairly >>>> amorphous, and it's not always possible to tell early on how big an >>>> instruction will be. It's possible in general of course, so it depends >>>> on what you actually mean there. Would chasing through linked lists like >>>> that slow things down a lot with memory dependencies, caching, etc.? >>> Let me be precise. Given a valid instruction array inst1 with length >>> i, is it ever possible for there to be a valid instruction array inst2 >>> of length j where j != i and inst1[k] == inst2[k] where 1 <= k <= >>> min(i,j). >> Yes, definitely. X86 defines a number of prefixes that can be applied in >> (almost) any combination, quantity and/or order at the start of an >> instruction. You can, unless I'm misremembering, specify any of the >> legacy prefixes 13 times in a row then another once, and then a one byte >> opcode. The same instruction could be encoded by exchanging the >> prefixes, moving the unique one around, etc. The possibilities aren't >> endless, but they're certainly numerous. > Oh, wait, inst1[k] == inst2[k]. I read that as !=. See the paragraph > below then. > >>> A concrete example. Is it ever possible for an instruction that's 8 >>> bytes long to have the same 8 bytes as the first 8 bytes of an >>> instruction whose length is greater than 8. >> In this case mostly no, unless you allow the mode to change. The inc/dec >> instructions in legacy/compat modes are repurposed as the REX (64 bit >> stuff) prefixes in 64 bit mode, so if you use those in one case it would >> be the opcode/end of the instruction, and in the other it would be >> followed by a bunch of stuff, at least an opcode byte.
And actually, let me expand on this part too. It's worse than what I have here. In the segment descriptors there are bits which determine what the various default sizes are (operand, address, stack) and these affect the size of immediate and displacement values encoded in the instruction. If these values change, the same bytes would stop encoding an instruction at the end of an immediate value in one place in one case and in another place in the other. Unfortunately if you're working with x86 and you think to yourself "Oh, they would never do that." you're likely wrong. Gabe _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
