The limit of 16 bytes was imposed by you when you defined it as only 4 dwords. You can define more if you wish to.

You can also read memory beyond the array bounds if you like. But it is probably not going to end up well for you. The CPU will try to follow your desires if it can, but don't rely on any sensible data being read or written.

You can also go negative if you wish to:

Okay, I think I get it. So the number of elements in eax is limited to 16, is that correct?

@Mino: You really need to understand how basic memory is. Here's some tips for illustration purposes.

Use a hex editor. Open a file. Imagine the file is memory data in RAM.

Each byte = 1 offset. If the file is 16 bytes, what do you think happens if you do [eax+17]??

You access a byte beyond the file, which you have no idea what it is (this is called a buffer overflow, a nasty security vulnerability). It could be garbage left by other stuff in there prior. It could be unallocated memory in which your app will just crash without an exception handler. etc. Memory and arrays are nothing special, they're just locations in memory like that.

Now open up a large file with a hex editor. Imagine this is your entire process' mapped RAM.

Your array is not the entire RAM, so select some bytes in that large file. Doesn't have to be from the beginning. Say select from offset 0xC0 to 0xD0 (16 bytes).

Do you see these bytes? Imagine they are your array. When you use "MyArray" in code it "translates" here to 0xC0 in this example. 0xD0 is beyond your array, the last element is 0xCF. Memory exists beyond your array (can be code, or data, or garbage, or unallocated), but it's not a good idea to access it.

Seriously, memory is not magic. It always "exists" when allocated. Labelling it (like MyArray) is just syntactic sugar, it doesn't "allocate" anything or hocus pocus. It just refers to it. There is no "hidden object" or whatever. It's just... data... that exists.

Of course you can make MyArray larger, then it will refer to more memory. Let's say you have this: This means MyArray just refers to a memory that is laid out like a consecutive sequence of 4 byte integers starting from 0. How many? Well it's guaranteed to be from 0 to 11 inclusive, yes since Stuff follows directly after.

dword [Stuff] is 10, dword [Stuff+4] is 11. [MyArray+40] may be "beyond" MyArray but since you placed the rest of the data after, it will be the same as [Stuff] -- literally, it will refer to the same location. In hex it's like (little endian): What's after 0B 00 00 00? Unless you placed something afterwards, it's probably garbage or unallocated memory, i.e. don't touch it.

If you put an instruction, then the instruction encoding itself will follow (if same section). Instructions are just bytes in RAM, too. For example, nop is 0x90, so if you had: Then this would be like this in memory:

Hoo! I understand better now, everything becomes more lucid .
Now, I think I've understood a lot about not only arrays, but memory management in assembler...

Thank you both so much !

EAX is just a register. It has 32 bits. It can point to a memory address. The memory address can contain a variable number of bytes, maybe 0 bytes, maybe 1 byte, maybe 4 gigabytes. Or EAX can simply contain just a number.

Numbers can also be addresses. Addresses can also be numbers. There is no distinction between addresses and numbers, they are all just 32 bit values which you can interpret in your code to be whatever you need them to be.

Numbers can also be integers, or floating point values, or fixed point values, or flags, or just a random collection of bits. And a register can hold all of those things at the same time. A register simply stores whatever you put there, and gives it back later whenever you ask for it.

You can think of registers as a very fast type of memory.