Subject: Re: AVX issue: to have a leading V or not? - msg#00001

Previous Message by Date: click to view message preview

Re: AVX issue: to have a leading V or not?

[Cc: nasm-devel] Peter Johnson wrote: > A related topic: what should the nomenclature be for the 256-bit > (32-byte) memory size? Considering "oword" is used for 128-bit, what > comes next? "hword" or "hxword" ("hword" is used in gas to mean > "halfword", so I'm a bit reluctant to use it to mean 16 words)? > Something completely different like "bytex32" or "ymem" (after ymm)? > Considering it's all SIMD, I'm not sure a dq-type psuedo-instruction for > it is needed, although I could see the argument for a resq-type > psuedo-instruction. > > On the other hand, one might make the argument that one's not needed at > all, since I think all possible usages can just be unspecified size. > MASM must use something as it has to have a datatype for it (e.g. DWORD > PTR), but NASM shouldn't need to. It doesn't, but I think experience shows that it's good to try to stick with orthogonality. nasm64developer suggested "yword" and "dy", after "ymm", which obviously don't make any sense but is still highly mnemonic. Arguably the fact that it doesn't make any sense is actually a good thing. "xword", which would be the most logical mnemonic, seems like poison for confusion with "xmm", so I'm going to second nasm64developer's proposal. -hpa ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

Next Message by Date: click to view message preview

AVX and VEX

The new Intel AVX specs definitely introduces a whole lot of "interesting" things that are going to be "fun" to annotate. It's easy enough to parse, so the disassembler is okay, but what's really nasty is that they introduced alternate forms of the same instructions -- but with *different behaviour*. In particular, SSE instructions can now be encoded both in the "legacy" way and with the new VEX prefix. When encoded with VEX, the upper 128 bits ("YMM") of registers are cleared, but with "legacy" encoding, the YMM bits are left unchanged. With REX, DREX and now VEX (which keeps making me think of CPU Wars, http://www.e-pix.com/CPUWARS/cpuwars.html) I'm thinking we need to be able to parse prefixes like "rex.w.b" and actually do something sensible with them. OTOH, first we need to make this work at all. -hpa ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

Previous Message by Thread: click to view message preview

Re: AVX issue: to have a leading V or not?

[Cc: nasm-devel] Peter Johnson wrote: > A related topic: what should the nomenclature be for the 256-bit > (32-byte) memory size? Considering "oword" is used for 128-bit, what > comes next? "hword" or "hxword" ("hword" is used in gas to mean > "halfword", so I'm a bit reluctant to use it to mean 16 words)? > Something completely different like "bytex32" or "ymem" (after ymm)? > Considering it's all SIMD, I'm not sure a dq-type psuedo-instruction for > it is needed, although I could see the argument for a resq-type > psuedo-instruction. > > On the other hand, one might make the argument that one's not needed at > all, since I think all possible usages can just be unspecified size. > MASM must use something as it has to have a datatype for it (e.g. DWORD > PTR), but NASM shouldn't need to. It doesn't, but I think experience shows that it's good to try to stick with orthogonality. nasm64developer suggested "yword" and "dy", after "ymm", which obviously don't make any sense but is still highly mnemonic. Arguably the fact that it doesn't make any sense is actually a good thing. "xword", which would be the most logical mnemonic, seems like poison for confusion with "xmm", so I'm going to second nasm64developer's proposal. -hpa ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

Next Message by Thread: click to view message preview

AVX and VEX

The new Intel AVX specs definitely introduces a whole lot of "interesting" things that are going to be "fun" to annotate. It's easy enough to parse, so the disassembler is okay, but what's really nasty is that they introduced alternate forms of the same instructions -- but with *different behaviour*. In particular, SSE instructions can now be encoded both in the "legacy" way and with the new VEX prefix. When encoded with VEX, the upper 128 bits ("YMM") of registers are cleared, but with "legacy" encoding, the YMM bits are left unchanged. With REX, DREX and now VEX (which keeps making me think of CPU Wars, http://www.e-pix.com/CPUWARS/cpuwars.html) I'm thinking we need to be able to parse prefixes like "rex.w.b" and actually do something sensible with them. OTOH, first we need to make this work at all. -hpa ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace