www.digitalmars.com         C & C++   DMDScript  

c++.dos.32-bits - Re: REP MOVSD

reply "Nic Tiger" <nictiger pt.comcor.ru> writes:
I recently encountered interesting thing (when I was compiling with DMC 8.28
my code with inline asm):
 rep movsd instruction is reported to have 2 arguments
*******
  rep movsd
          ^
rep.cpp(5) : Error: 2 operands expected for the movsd instruction, had 0
*******

When I turned to Intel's spec, I've found out that THERE ARE 2 absolutely
equal mnemonics for 2 absolutely different opcodes:
    MOVSD - move dword from DS:ESI to ES:EDI (string operation)
    MOVSD - move scalar double-precision floating-point value (SIMD)

So, since DMC 8.28 has support for SIMD instructions, the second case takes
place in DMC.

I've found that replacing old
  REP MOVSD
to
  REP MOVS dword ptr ds:[esi], dword ptr es:[edi]

fixes problem, because according to Intel's spec they are equivalent, but
the latter is explicit form.

I hope this will be helpful for someone who encountered the same problem.

Nic Tiger.

P.S. Interesting enough, but when using MOVSD without REP prefix compiler
chooses MOVSD version correctly. May be it is a compiler's bug and in case
of REP it
should do the same.
Jun 21 2002
next sibling parent reply Roland <rv ronetech.com> writes:
interesting

is rep movs still a little slower than mov eax,[esi]; add  esi,1; mov
es:[edi],eax; add edi,1; .. as it was in the 486 ?

roland


Nic Tiger a écrit :

 I recently encountered interesting thing (when I was compiling with DMC 8.28
 my code with inline asm):
  rep movsd instruction is reported to have 2 arguments
 *******
   rep movsd
           ^
 rep.cpp(5) : Error: 2 operands expected for the movsd instruction, had 0
 *******

 When I turned to Intel's spec, I've found out that THERE ARE 2 absolutely
 equal mnemonics for 2 absolutely different opcodes:
     MOVSD - move dword from DS:ESI to ES:EDI (string operation)
     MOVSD - move scalar double-precision floating-point value (SIMD)

 So, since DMC 8.28 has support for SIMD instructions, the second case takes
 place in DMC.

 I've found that replacing old
   REP MOVSD
 to
   REP MOVS dword ptr ds:[esi], dword ptr es:[edi]

 fixes problem, because according to Intel's spec they are equivalent, but
 the latter is explicit form.

 I hope this will be helpful for someone who encountered the same problem.

 Nic Tiger.

 P.S. Interesting enough, but when using MOVSD without REP prefix compiler
 chooses MOVSD version correctly. May be it is a compiler's bug and in case
 of REP it
 should do the same.

Jun 21 2002
parent reply "Javier Gutiérrez" <nikkho nospam.hotmail.com> writes:
    Generally for 486 and later the RISC form is faster.
    Going further, using the FPU registers or MMX instructitions if
available is even faster, because you can move 64 and 128 bit at a time.
    BTW your sample source was wrong, since esi and edi should be
incremented 4 times being:

    mov eax, [esi]
    add esi, 4
    mov es:[edi], eax
    add edi, 4


"Roland" <rv ronetech.com> escribió en el mensaje
news:3D12F02F.7066284F ronetech.com...
 interesting

 is rep movs still a little slower than mov eax,[esi]; add  esi,1; mov
 es:[edi],eax; add edi,1; .. as it was in the 486 ?

 roland


 Nic Tiger a écrit :

 I recently encountered interesting thing (when I was compiling with DMC


 my code with inline asm):
  rep movsd instruction is reported to have 2 arguments
 *******
   rep movsd
           ^
 rep.cpp(5) : Error: 2 operands expected for the movsd instruction, had 0
 *******

 When I turned to Intel's spec, I've found out that THERE ARE 2


 equal mnemonics for 2 absolutely different opcodes:
     MOVSD - move dword from DS:ESI to ES:EDI (string operation)
     MOVSD - move scalar double-precision floating-point value (SIMD)

 So, since DMC 8.28 has support for SIMD instructions, the second case


 place in DMC.

 I've found that replacing old
   REP MOVSD
 to
   REP MOVS dword ptr ds:[esi], dword ptr es:[edi]

 fixes problem, because according to Intel's spec they are equivalent,


 the latter is explicit form.

 I hope this will be helpful for someone who encountered the same


 Nic Tiger.

 P.S. Interesting enough, but when using MOVSD without REP prefix


 chooses MOVSD version correctly. May be it is a compiler's bug and in


 of REP it
 should do the same.


Jun 24 2002
parent Roland <rv ronetech.com> writes:
"Javier Gutiérrez" a écrit :

     Generally for 486 and later the RISC form is faster.
     Going further, using the FPU registers or MMX instructitions if
 available is even faster, because you can move 64 and 128 bit at a time.
     BTW your sample source was wrong, since esi and edi should be
 incremented 4 times being:

     mov eax, [esi]
     add esi, 4
     mov es:[edi], eax
     add edi, 4

oops ! I'm going to fire me roland
Jun 25 2002
prev sibling parent "Nic Tiger" <nictiger pt.comcor.ru> writes:
Also I ran into the same problem with CMPSD (while trying compile DOSX
runtime library).

Nic Tiger.

"Nic Tiger" <nictiger pt.comcor.ru> wrote in message
news:aeukk3$11ua$1 digitaldaemon.com...
 I recently encountered interesting thing (when I was compiling with DMC

 my code with inline asm):
  rep movsd instruction is reported to have 2 arguments
 *******
   rep movsd
           ^
 rep.cpp(5) : Error: 2 operands expected for the movsd instruction, had 0
 *******

 When I turned to Intel's spec, I've found out that THERE ARE 2 absolutely
 equal mnemonics for 2 absolutely different opcodes:
     MOVSD - move dword from DS:ESI to ES:EDI (string operation)
     MOVSD - move scalar double-precision floating-point value (SIMD)

 So, since DMC 8.28 has support for SIMD instructions, the second case

 place in DMC.

 I've found that replacing old
   REP MOVSD
 to
   REP MOVS dword ptr ds:[esi], dword ptr es:[edi]

 fixes problem, because according to Intel's spec they are equivalent, but
 the latter is explicit form.

 I hope this will be helpful for someone who encountered the same problem.

 Nic Tiger.

 P.S. Interesting enough, but when using MOVSD without REP prefix compiler
 chooses MOVSD version correctly. May be it is a compiler's bug and in case
 of REP it
 should do the same.

Jun 22 2002