flat assembler - mov vs cmove (with the identical arguments)

Index > Windows > mov vs cmove (with the identical arguments) - OK vs Error

Author

Thread

fatygant

Joined: 12 Sep 2011
Posts: 30
Location: Poznan, Poland

fatygant 07 Feb 2018, 20:40

Hello!

I have another problem which makes me scratch top of my head... I would appreciate your explanation.

I have two instructions in my 64-bit Windows code (of course they do not come one after another):

Code:

mov   rax,modbus_ascii_txt
cmove rax,modbus_ascii_txt

The first one is assembled with no problems - but the second one generates the error: invalid argument. modbus_ascii_txt is just a memory address of the string defined as 'Modbus ASCII',0.

How is this possible if they work with the same type of operands according to x86_64 documentation?

Many thanks for your help!

07 Feb 2018, 20:40

alexfru

Joined: 23 Mar 2014
Posts: 80

alexfru 07 Feb 2018, 23:55

cmovcc's source operand is either a register or a memory operand. It does not take an immediate.

07 Feb 2018, 23:55

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20667
Location: In your JS exploiting you and your system

revolution 08 Feb 2018, 03:15

It is a serious oversight on Intel's part. CMOVcc doesn't support immediate operands, as alexfru states.

One possible way around it is this:

Code:

mov rdx,modbus_ascii_txt ; use a temporary register
cmove rax,rdx

08 Feb 2018, 03:15

fatygant

Joined: 12 Sep 2011
Posts: 30
Location: Poznan, Poland

fatygant 08 Feb 2018, 08:35

Thank you alexfru and revolution!

08 Feb 2018, 08:35

MatQuasar

Joined: 25 Oct 2023
Posts: 105

MatQuasar 14 May 2024, 10:56

Learned 'cmove' today from Ville's example code in another thread. It cuts down at least two unnecessary branches.

Code:

_str1 db '1'
_str2 db '2'
_input rb 1  

  lea    eax, [_str1]
  lea    ebx, [_str2]
  cmp    [_input], '1'
  cmove  ebx, eax

Code:

_str1 db '1'
_str2 db '2'
_input rb 1  

  cmp    [_input], '1'
  jz     .f
  lea    ebx, [_str2]
  jmp    .g

.f:
  lea    ebx, [_str1]

.g:

Last edited by MatQuasar on 14 May 2024, 11:07; edited 1 time in total

14 May 2024, 10:56

MatQuasar

Joined: 25 Oct 2023
Posts: 105

MatQuasar 14 May 2024, 11:04

But both sizes are same:

Code:

PS C:\Users\User\projects> format-hex a.bin


           Path: C:\Users\User\projects\a.bin

           00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000   31 32 00 66 8D 06 00 00 66 8D 1E 01 00 80 3E 02  12.f...f...>.
00000010   00 31 66 0F 44 D8                                .1f.DØ


PS C:\Users\User\projects> format-hex b.bin


           Path: C:\Users\User\projects\b.bin

           00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000   31 32 00 80 3E 02 00 31 74 07 66 8D 1E 01 00 EB  12.>..1t.f...ë
00000010   05 66 8D 1E 00 00                                .f...


PS C:\Users\User\projects> dir *.bin


    Directory: C:\Users\User\projects


Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----         14/5/2024   7:02 PM             22 a.BIN
-a----         14/5/2024   7:03 PM             22 b.BIN

But if put "use32", there is difference by 1 byte, "cmove" version is shorter.

14 May 2024, 11:04

bitRAKE

Joined: 21 Jul 2003
Posts: 4249
Location: vpcmpistri

bitRAKE 14 May 2024, 12:02

Coding for size, we'd use:

Code:

    cmp [_input], '1'
    mov eax, _str1
    cmove eax, [_other]

... but it cost four more bytes of data, and still doesn't beat the non-CMOV:

Code:

    mov eax, _str1
    cmp [_input], '1'
    jz @F
    add eax, _str2-_str1
@@:

... size coding [usually] favors legacy instructions and tricky manipulations.

We loose RIP addressing and need relocation data, etc. It's all trade-offs depending on what you need.

Edit: the FPU probably wins the code density prize: FBSTP [RSI] ; two bytes for all that!
(Ignoring system instructions.)

_________________
¯\(°_o)/¯ “languages are not safe - uses can be” Bjarne Stroustrup

14 May 2024, 12:02

MatQuasar

Joined: 25 Oct 2023
Posts: 105

MatQuasar 14 May 2024, 17:14

Good and efficient codes, bitRAKE.

14 May 2024, 17:14

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum