from intel manual:
Quote
MOVQ r/m64,xmm | Move quadword from xmm register to r/m64.
r/m64 — A quadword general-purpose register or memory operand used for
instructions whose operand-size attribute is 64 bits when using REX.W.
Quadword general-purpose registers are: RAX, RBX, RCX, RDX, RDI, RSI, RBP,
RSP, R8–R15; these are available only in 64-bit mode. The contents of memory
are found at the address provided by the effective address computation.
my code:
movq rcx, xmm1
assembler error:
Quote
Error!
..
Invalid operand for this mnemonic:-
movq rcx, xmm1
Don't say I'm the first to use such "complex" instruction & that it's a bug...
Simple question : Do you used x86 or x64 option in the command line ?
Patrick
My whole development environment is tuned for x64 platform now :} (well mostly *.bat files) so don't worry 'bout that
Also there is a problem with (throws an error):
mov r8l, [rsi+rcx+1]
mov B[rdi], r8l
but instead
mov al, [rsi+rcx+1]
mov B[rdi], al
compiles fine
maybe in goasm r8l = r8b .. but that's not Intel's notation
hi,
the movq instruction (SSE2) supports only mmx/xmm registers and mem64 -> use movd
regards, qWord
do you need a .MMX directive, perhaps ?
qWord is true, you can't use rcx with movq.
And what is r8l ?
Only r8b, r8w, r8d and r8 are allowed.
Patrick
Then how come Intel manual 253666.pdf (3-660 Vol. 2A) says
there is such instruction (who lie?):
Quote
66 REX.W 0F 7E /r MOVQ r/m64, xmm Valid N.E. Move quadword from xmm register to r/m64.
And
r8l is Intel's valid notation for r8 register's 8 least significant bits .. not
r8band existence of such inst. really would make sense:
movq -> move quadword.
rcx -> quadword
movq rcx, xmm1 -> sends lower 64 xmm1 bits to rcx register
hi,
you're right, Intel's documents are a bit confusing. You can find two entry's for movq in Vol 2A: "MOVD/MOVQ—Move Doubleword/Move Quadword" and "MOVQ—Move Quadword" (AMD's documents are much more clear in this point).
The first uses GPR's while the second only supports mmx/xmm registers. In the former case, the only difference between movd and movq is the REX.w prefix - that may be the reason why goasm (and masm) doesn't like such use of movq.
regards, qWord
Conclusion ?
movq rcx, xmm1 ; this instruction must be implemented in GoAsm. :'(
r8l ; this mnemonic must be implemented in GoAsm. (r0, r1, r2,... also) :'(
Patrick
My conclusion is if:
movd rcx, xmm1 really does the job -
send 64 bits from xmm register then that's ok with me.
And regarding r8l .. r15l - that's Intel's notation
and r8b .. r15b - that's AMD notation (i didn't know earlier).
So I can live with r8b - no big deal.
QuoteMy conclusion is if:
movd rcx, xmm1 really does the job -
send 64 bits from xmm register then that's ok with me.
but >>> send 32 bits from xmm register.
Yes, you can insert the rex byte before the instruction to change it to 64 bits. :tdown
Jeremy : Can you implement a normal syntax ? ::)
Patrick
Hi all
I'll look into this and come back to you.
Hi Jeremy,
When using FPU, I noticed that the FISTTP instruction is not supported by GoAsm. Not a big deal, of course, but I think it could be convenient sometimes. What is your opinion on that?
Quote
FISTTP — Store Integer with Truncation
Opcode Instruction 64-Bit Mode Compat/Leg Mode Description
DF /1 FISTTP m16int Valid Valid Store ST(0) in m16int with truncation.
DB /1 FISTTP m32int Valid Valid Store ST(0) in m32int with truncation.
DD /1 FISTTP m64int Valid Valid Store ST(0) in m64int with truncation.
FISTTP appears to be SSE3.
Personally, I decided against asking Jeremy if he could add this because programming for windows is already so abstract and convoluted. Many PC's still do not support SSE3, so any code we plan on releasing will require coding earlier extension versions as well.
If you wanted to try the FISTTP instruction literally, see the bottom here:
http://www.ray.masmcode.com/tutorial/fpuchap5.htm
Oh, thanks for the info, Mark. I would have never thought it's somehow connected to SSE3. Then I think you are right. It's useless even for me because of my Athlon XP.
On the question of MOVD and MOVQ ..
ramguru started the thread because when wanting to move 64-bits (a quadword) from the low part of an XMM register to a 64-bit general purpose register, he found that the following instruction:-
MOVQ RCX,XMM1
returned the error "Invalid operand for this mnemonic" in Goasm
This accords with the AMD64 manual which specifies the following instruction instead
MOVD RCX,XMM1
GoAsm assembles the above instruction correctly so that it works with 64-bits, ie the REX byte is included in the output.
However, the Intel documentation for the EM64T processor says that the MOVQ instruction is valid.
In other words, according to Intel,
MOVQ RCX,XMM1
will do what AMD says is done by
MOVD RCX,XMM1
I do not know why AMD did not suggest the use of MOVQ here, after all, this instruction does move a qword.
In the circumstances I would propose to amend GoAsm to add support for the MOVQ variant here. GoAsm would therefore give the same output in both cases. The only thing which would stop me doing this is the possibility that AMD might be planning to use MOVQ for some other purpose which would conflict with this use. However, that seems unlikely now in the light of the Intel documentation.
Does anyone have any objections to this change?
.intel
and
.amd
directives ?
just a thought
Quote .intel
and
.amd
Maybe, except that I have tried to avoid processor directives since they are another thing to get wrong or result in strange effects (and also rapidly get out of date).
I don't mind if it stays as it is.
I've suspected that movd really worked as movq with 64bit registers.
Tried to modify the opcode (by hand) & couldn't make disassembler
interpret it as movq (so yeah most of disassemblers follows faulty AMD notation :/ )
well, the advantage of using the directives is, you can maintain backward compatibility in the future
i don't see ".amd" or ".intel" as any better or worse than ".586" or ".686"
in fact, it is slightly milder, as a program written with ".amd" may be run on an intel processor and one with ".intel" may be run on amd
keep in mind, that it only affects interpretation of a few instructions
it does not neccessarily change any generated code
pick the one you like the best and call it default - lol
in this case, i dislike amd's use of movd, so my vote for default would be .intel
however, as long as they are aware of the reprecussions, i say let the programmer choose
again, it's only food for thought
Intel way is the right way, as always. :bdg
Not having to use ".386" or other directives is one of the things I like about GoASM. :bg