0

So I have this array:

fib BYTE 9, 123, 92, 0, 0, 0, 0

And I'm wanting to be able to access the different elements of the array and move them, individually, into a register.

I've noticed so far that I can, for example, do this:

mov al, fib + 2

to move the 3rd elements value, 92, into the al register.

However, if I try to do this:

mov ah, 2
mov al, fib + ah

so that I can change the value of ah and thus change the element that I am moving into al, the assembler says that the second line is an "invalid use of a register"

So my question is, is there any way that I can rewrite that second line in a way that would allow me to access the value of the element in the fib array that is offset, from the beginning, by the value that is stored in ah?

Edit:

I am writing this code in Visual Studio on Windows 10. The target platform is x86. The entire source code is:

.386
.model flat, stdcall
.stack 4096
ExitProcess PROTO, dwExitCode: DWORD

.data

    fib     BYTE 9, 123, 92, 0, 0, 0, 0

.code

main PROC

    mov bx, 2
    mov al, [fib + bx]

    INVOKE ExitProcess, 0
main ENDP
END main

There's really not much to it considering this is just my attempt at learning more about arrays in assembly language

user3322166
  • 15
  • 4
  • 1
    If you are in 16 bit mode, you can only use a limited subset of addressing modes. Even in other modes, you should use the appropriately sized register. E.g. `mov bx, 2; mov al, [fib+bx]` is legal 16 bit code. – Jester Oct 14 '20 at 19:29
  • @Jester When I try out your suggestion, the project builds perfectly fine but then once I run the program, I get an access violation exception thrown at the line ```mov al, [fib + bx]``` – user3322166 Oct 14 '20 at 20:00
  • 1
    Is this 16-, 32- or 64-bit code (real / protected / long mode?) – Nate Eldredge Oct 14 '20 at 20:24
  • An access violation? I will assume you are running this as a MS Windows application? It doesn't sound like you are running in a 16-bit environment. – Michael Petch Oct 14 '20 at 20:48
  • @NateEldredge I'm assuming protected mode? It's being ran in debug mode in Visual Studio on Windows 10. – user3322166 Oct 14 '20 at 20:50
  • @MichaelPetch I am running this on Windows. – user3322166 Oct 14 '20 at 20:50
  • Yeah the access violation would have also included the number c0000005 . You need to write 32 bit or 64-bit code and that depends on whether your Visual Studio project is x86 or x64. You can't use 16-bit memory operands and expect to address the address space of a Windows application. – Michael Petch Oct 14 '20 at 21:02
  • Can you just show us your complete code and tell us if your Visual Studio project is targeting 32-bit (x86) or 64-bit (x64) platform. You can tell what platform by looking in the Visual Studio menu bar at the top - there is a drop down box that switches between `x86`/`x64` (but it will display the current target platform). Since your code actually assembled I have to guess the target platform is `x86` (32-bit) – Michael Petch Oct 14 '20 at 21:04
  • @MichaelPetch I edited my main post to show the complete code and discovered that the targeted platform is indeed x86. – user3322166 Oct 14 '20 at 21:18
  • 4
    In 32 bit mode you want 32 bit addressing, so do `mov ebx, 2; mov al, [fib + ebx]`. – Jester Oct 14 '20 at 21:23
  • @Jester That appears to be my mistake. It is working as expected now, after switching to ebx. Thank you! – user3322166 Oct 14 '20 at 21:27
  • Related, sort of a duplicate for the 8-bit register part: [Using 8-bit registers in x86-64 indexed addressing modes](https://stackoverflow.com/q/39173410). See comments on the question. – Peter Cordes Oct 15 '20 at 03:22
  • I may have been a bit hasty in closing this as a duplicate. I didn't find an ideal duplicate that explains that register size implies address-size (other than as a small part of my larger answer), so you should use pointer-width registers in addressing modes. If anyone wants to answer this, we can reopen. – Peter Cordes Oct 15 '20 at 04:41

0 Answers0