1

I'm trying to run this code and print the result, but for some reason I get this error message:

main.asm:10: error: invalid operands in non-64-bit mode 
main.asm:11: error: invalid operands in non-64-bit mode
main.asm:12: error: invalid operands in non-64-bit mode
main.asm:13: error: invalid operands in non-64-bit mode
ld: cannot find *.o: No such file or directory

This is the code:

global _start       
section .data
    n DB 10
section .text
_start:
    xor ax, ax
    mov bx, 1
    mov cx, (n)
.L1:
    mov r9w, bx    #one of the lines that leads to an error
    imul r9w, bx   #one of the lines that leads to an error
    imul r9w, bx   #one of the lines that leads to an error
    add ax, r9w    #one of the lines that leads to an error
    inc bx
    dec cx
    test cx, cx
    jne .L1
    
    movq rax, 1
    movq rdi, 1
    movq rsi, ax
    movq rdx, 8
    syscall

    xor rax, rax
    ret
END:

I am fairly new to assembly and can't quite understand what the problem is - the BX register is 16 bits, and R9W is also 16 bits...
I use an online compiler to run this (https://www.tutorialspoint.com/compile_assembly_online.php)

Sep Roland
  • 33,889
  • 7
  • 43
  • 76
SpaceNugget
  • 139
  • 1
  • 11
  • 1
    What commands do you type to assemble and link this code? It looks like you specified the wrong object type. Also note that you cannot return from `_start` as there is nothing to return to. Issue an exit system call instead. Lastly, it's really hard to debug uncommented code. Next time, try to comment each line with what you want it to do! If one line causes an error, point that line out! It's very hard to guess which line has which number, especially for longer programs. – fuz Nov 15 '22 at 13:04
  • Aside from the likely wrong object format as @fuz suggested, `movq` is not a valid instruction mnemonic in NASM. Use a plain `mov` instead. – ecm Nov 15 '22 at 13:06
  • `mov cx, (n)` will load the address of `n` not the contents. Use brackets `[...]` in NASM source to load from memory. `db` should be `dw` for loading into `cx` however. – ecm Nov 15 '22 at 13:08
  • 1
    Do not use online tools to assemble code. This online tool in particular does not seem to be designed to build amd64 Linux binaries. Install nasm onto your Linux system and do it locally instead. – fuz Nov 15 '22 at 13:10
  • 3
    That online tool is presumably building for 32-bit mode, `nasm -felf32`, which matches the example code it opens with. And it doesn't have a debugger to let you single-step running code, so it's near useless for learning asm. It's worth the time to get a working debugger set up as part of a development environment, so you can single-step and watch regs change. Without that, you'll waste tons of time guessing about where a problem might be when a debugger would make it obvious. – Peter Cordes Nov 15 '22 at 13:29
  • 2
    This is an exercise in learning to read error messages. "invalid operands in non-64-bit mode." So the operands are supported only in 64-bit mode. Specifically, `r9w` requires 64-bit mode. – Raymond Chen Nov 15 '22 at 14:54
  • 3
    To be pedantic, `movq` *is* a [valid instruction mnemonic](https://www.felixcloutier.com/x86/movd:movq) in Intel syntax, but it isn't the instruction you want; you do want plain `mov` here. – Nate Eldredge Nov 15 '22 at 15:26

1 Answers1

3

I see three main problems with your code:

  1. You are attempting to access a 64-bit register in a non 64-bit mode. Despite R9W being the lowest part of the R9 register it is still 64-bit mode only.
  2. You are attempting to return from _start by executing the ret instruction. This can cause a segmentation fault because the stack currently contains a pointer to argc
  3. You should probably use the mov instruction rather than the movq instruction.
Markian
  • 322
  • 1
  • 12
  • 1
    A `ret` instruction from `_start` isn't "harmless", it will crash because `qword [rsp]` holds `argc`, not a return address. (Or `dword [esp]` in 32-bit mode). [Nasm segmentation fault on RET in \_start](https://stackoverflow.com/q/19760002) – Peter Cordes Dec 06 '22 at 23:13