Re: Implement INVLPGA according to the documentation

> INVLPGA is defined as taking rax,ecx but "the
portion of rax used to
> form the address is determined by the effective address
size", so it
> is really ax/eax/rax.

Technically the proper syntax is INVLPGA [rAX],ECX -- that
is, the
first operand is a memory operand that can only use rAX.

Here is a list of these difficult to implement instructions
-- one way
to deal with them is to omit these implied operands from
insns.dat
and document them in the user manual instead.

- LODS[BWDQ] and OUTS[BWD] imply [DS:rSI]
- STOS[BWDQ], SCAS[BWDQ], and INS[BWD] imply [ES:rDI]
- CMPS[BWDQ] and MOVS[BWDQ] imply [ES:rDI],[DS:rSI]
- XLATB implies [DS:rBX]
- MASKMOVQ and MASKMOVDQU imply [DS:rDI]
- PBLENDVB, BLENDVPS, and BLENDVPD imply XMM0
- PCMPESTRM implies rAX and rDX, and XMM0
- PCMPESTRI implies rAX and rDX, and rCX
- PCMPISTRM implies XMM0
- PCMPISTRI implies rCX
- MONITOR implies [DS:rAX],ECX,EDX
- MWAIT implies EAX,ECX
- GETSEC implies EAX (as well as EBX and/or ECX and/or EDX)
- VMRUN implies [rAX]
- VMLOAD and VMSAVE imply [rAX]
- SKINIT implies [EAX]
- INVLPGA implies [rAX],ECX
- GX1_CPU_WRITE and GX1_CPU_READ imply EBX and EAX
- ALTINST without operands implies [CS:EAX]
- MONTMUL implies EAX, ECX, and [ES:eSI]
- XSHA[1|256] implies EAX, ECX, and [ES:e[SI|DI]]
- XSTORE implies [ES:eDI] and eDX
- XCRYPT[ECB|CBC|CTR|CFBFB]
implies [ES:e[AX|BX|DX|SI|DI]] and eCX

- A segment prefix can be used to override the DS segment.

- An explicit address size prefix (A16/A32/A64) can be used
to over-
  ride the default address size (i.e. the "r" in
[rEGISTER]).

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Nasm-devel mailing list
Nasm-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nasm-devel

anonymous coward wrote:
>> INVLPGA is defined as taking rax,ecx but "the
portion of rax used to
>> form the address is determined by the effective
address size", so it
>> is really ax/eax/rax.
> 
> Technically the proper syntax is INVLPGA [rAX],ECX --
that is, the
> first operand is a memory operand that can only use
rAX.

That doesn't match the syntax specified in the documentation
(not that
the CPU vendor docs always make sense), though.  There are a
bunch of
those, and I personally prefer the unadorned form, but since
it's
documented as such I figured I'd implement it.

> Here is a list of these difficult to implement
instructions -- one way
> to deal with them is to omit these implied operands
from insns.dat
> and document them in the user manual instead.
> 
> - LODS[BWDQ] and OUTS[BWD] imply [DS:rSI]
> - STOS[BWDQ], SCAS[BWDQ], and INS[BWD] imply [ES:rDI]
> - CMPS[BWDQ] and MOVS[BWDQ] imply [ES:rDI],[DS:rSI]
> - XLATB implies [DS:rBX]
> - MASKMOVQ and MASKMOVDQU imply [DS:rDI]
> - PBLENDVB, BLENDVPS, and BLENDVPD imply XMM0
> - PCMPESTRM implies rAX and rDX, and XMM0
> - PCMPESTRI implies rAX and rDX, and rCX
> - PCMPISTRM implies XMM0
> - PCMPISTRI implies rCX
> - MONITOR implies [DS:rAX],ECX,EDX
> - MWAIT implies EAX,ECX
> - GETSEC implies EAX (as well as EBX and/or ECX and/or
EDX)
> - VMRUN implies [rAX]
> - VMLOAD and VMSAVE imply [rAX]
> - SKINIT implies [EAX]
> - INVLPGA implies [rAX],ECX
> - GX1_CPU_WRITE and GX1_CPU_READ imply EBX and EAX
> - ALTINST without operands implies [CS:EAX]
> - MONTMUL implies EAX, ECX, and [ES:eSI]
> - XSHA[1|256] implies EAX, ECX, and [ES:e[SI|DI]]
> - XSTORE implies [ES:eDI] and eDX
> - XCRYPT[ECB|CBC|CTR|CFBFB]
implies [ES:e[AX|BX|DX|SI|DI]] and eCX
> 
> - A segment prefix can be used to override the DS
segment.
> 
> - An explicit address size prefix (A16/A32/A64) can be
used to over-
>   ride the default address size (i.e. the "r"
in [rEGISTER]).

... which is why also accept eax and ax.

	-hpa

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Nasm-devel mailing list
Nasm-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nasm-devel