Hi Ryan. For unimplemented instructions, those suffixes are just there for documentation purposes and don't do anything. For implemented instructions, they get processed by the code in src/arch/x86/isa/specialize.isa which uses them to determine where the instructions arguments come from and what size they are. They could be fixed registers, encoded in some part of the instructions encoding, implied in some way, etc. The capital letter determines what the data is (type of register, memory location, etc.), and the small letters say what size that thing should be treated as. This is basically the scheme from AMD's manuals (and likely elsewhere) at the start of appendix A in Volume 3.
Looking at that table, while I see V and W which go with XMM registers and potentially memory for W, I don't see the dq size suffix. I suspect either that was a typo, or, more likely, they moved to some different tags when they added new sizes like 256 bit registers. The size tags themselves are interpreted by the EmulEnv class in src/arch/x86/isa/macroop.isa where they set the operand size for the entire instruction, checking to make sure that the size isn't set more than once in an inconsistent way. The code in specialize.isa will, however, ignore the size suffix for XMM and MMX operands since the instructions will need to handle the abnormally large registers specially anyway. In that case, the suffix is just for documentation, and you'll need to make sure your microcode explicitly specifies an appropriate data size if it needs to. It also ignores the size on immediates and a couple other cases where an instruction might generally use, say, default sized integer registers, but always take a single byte immediate for some reason. The data size in that case should be the size of the registers, not the size of the immediate which is scraped out of the instruction encoding. So that's the relatively long answer. The shorter version is it doesn't really matter, the dq is just there to tell you what the instruction is supposed to operate on. You could carry it forward to be consistent (that's probably a good idea for now), and in your microcode you need manually ensure that the microops are working with data that's the right size. Gabe On Thu, May 24, 2018 at 5:14 PM Ryan Wang <[email protected]> wrote: > Hi, > (Particularly to Gabe). > > I need to implement a few SSE instructions (got segfault later, so suspect > that this is the reason). > these instructions happen to be inside three_byte_0f38_opcodes.isa like > pshufb_Vdq_Wdq(). I think I got to know what "V" and "W" mean, but don't > find information about "d" and "q". Can you please provide some hint? > > Regards, > Ryan > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
