Hi Gabe, Thanks a lot for your reply. It is now much clearer to me. Regards, Ryan
On Thu, May 24, 2018 at 8:26 PM, Gabe Black <[email protected]> wrote: > 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 _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
