Rust abstraction -> memory

I've been reading (3) different books on RUST. "THE RUST PROGRAMMING LANGUAGE" is one of them. They all teach the abstraction, but none of them seem to explain how exactly the abstraction relates to how the memory is actually being manipulated. Does anyone know of a resource that does this very thing?

Have you looked at Rust for Rustaceans? I recall that it starts out with giving an understanding of memory.

I'm interested in learning what each function/method is doing. How each of them interact with the memory, instead of just the abstraction itself. Does it do this, or is it just a cursory overview at the beginning?
As the mantra goes, in order to really be good at what one does, one must understand something at a certain level, and then understand one level deeper.

In this case, the best call might be to just look through the source code, diving into the functions being called, until you get either some common abstraction (like Box) or the direct pointers manipulation.

1 Like

What about writing snippets on the playground and looking at the generated assembly?

For example, if you want to see how as casts and function calls work, you can try a snippet like this:

pub fn add(a: u32, b: u64) -> u64 {
    a as u64 + b
}

(playground)

When compiling in release mode and selecting "Show Assembly" in the top-left corner, I see this:

playground::add:
	movl	%edi, %eax
	addq	%rsi, %rax
	retq

Which tells me that our a argument starts off in the %edi register and we immediately copy it to %eax. Next, the b argument (initially stored in %rsi) gets added to %rax and the result is stored back in %rax (i.e %rax = %eax + %rsi).

Something to note is that %eax is just the lower 32-bits of the 64-bit %rax register, which means a "cast" from a smaller number to a larger one is just a case of loading the smaller number's bits into the right part of the destination register. Also, when add runs it must implicitly assume all bits of %rax are zeroed out by the caller so we don't have any gunk left in %rax's higher 32-bits from previous instructions.

We didn't need to do any shuffling of values between registers after the addq instruction, so that means the caller expects the return value to be in %rax.

3 Likes