CODEWITHSUNDEEP
assemblymemorywebassembly
Reality
Reality

Reputation: 677

What is the relation to the order of which memory is stored

I have been trying and failing to understand [calculating] offsets in memory management.

The reason I want to do this is because I need to pass an array to WASM to subtract it, which is not possible due to WASM having only number types. Someone told me to achieve this I would have to calculate offset and pass in a typed array via JavaScript.

I understand that offsets are just what they sound like - the distance from the location of one address to another, but I don't exactly know how to calculate it. The resources I have found are good at explaining what it is, but I can't, for the life of me, find out the relation between the memory addresses to calculate offset.

I don't understand how to calculate offset, because I don't exactly know the order of memory stored (E.g: Is memory stored in climbing order like 0x001, 0x002, 0x003).

So, to answer the question about calculating offset, I have to first answer the main question - what is relation to the order of which memory is stored.

This is all confusing to me because I come from a high-level language environment where you don't typically work with offsets and memory addresses.

Resources I used to [try to] help me on this subject:

Upvotes: 1

Views: 66

Answers (1)

Peter Cordes
Peter Cordes

Reputation: 365267

At the simplest level, yes, memory is like a giant array whose elements are bytes.
(Assuming a normal modern computer architecture, one that's byte-addressable not word, flat memory model, etc.)

A wider access can load multiple bytes at once, as an integer (or as an FP double like JavaScript numbers that aren't in a TypedArray).

An array is just a range of addresses. (Or a start address and a length, or start and end addresses). Offsets into an array are used (in real CPU assembly) by accessing "the memory" at an address of start + offset, where start is the address of the array's first element. e.g. in x86-64 assembly, mov eax, [rdi + rsi*4] / ret implements the C function

int32_t idx_arr(int32_t *array_start, size_t index) {
    return array_start[index];        // mov eax, [rdi + rsi*4]
}

Notice that in asm, you have to manually scale the index by the element-size to get an offset in bytes.

Fun fact, return *(array_start+index); is exactly identical because C defines the [] operator in terms of pointer math. And normally you'd just call your pointer arg array; I used array_start to make the point that in assembly, you normally just get a pointer to the start, and sometimes the length or end_ptr as a separate arg so you can loop over it.

An array object or slice that knows its own length is a high-level construct, something you could implement with a data structure containing 2 pointers.

I don't know how much of this applies to Web Assembly, sorry; there you might actually get a TypedArray that can still do bounds-checking to stop you from writing or reading outside the array boundaries. In asm for real CPUs (or in C), nothing prevents that if you don't manually check the index against a known length, or prove that it will be in bounds based on loop logic or known contents of where you got the index from.

Upvotes: 2

Related Questions