Registers and subtyping

[Mesabloo]

Let's suppose that we have %rax: *s64 (which means that there is a pointer to a s64 in %rax).

On X86 (and X64) we have this register scheme:

Register size	~	~	~	~	~	~	~	~
64 bits	RAX	RAX	RAX	RAX	RAX	RAX	RAX	RAX
32 bits					EAX	EAX	EAX	EAX
16 bits							AX	AX
8 bits							AH
8 bits								AL

So we see that %eax is the bottom half of %rax, and %ax is the bottom half of %eax.
While this is not a problem at all in plain assembly language (because everything is a number), introducing types makes it harder.

Considering the example on top of the issue, what would be in %eax? A u32? Or maybe we could disallow this because %rax is a pointer?
What about if %rax: s64? Then we can safely assume that there is a valid s32 in %eax. (which is basically just %rax & 0xFFFFFFFF)

So we end up with some sort of subtyping relation on the type contained. The same thing can be observed the other way round (if we have %eax: s32, then we can assume there is %rax: s64).

---

While this approach seems good enough (we just need to reject cases where we want to get the lower half of, for example, a pointer), I feel like there is a better way of handling this.

[Mesabloo]

To complete this issue, we could also introduce a warning system when trying to access, for example, %eax: s32 from %rax: s64 (because this can be harmful to the data in %rax, for example add %eax, 1 will not increment %rax by one necessarily).
However, trying to access %eax: s32 from %rax: s32 is completely safe because both types have the same size (and, well, are the same type) so data will remain valid because you restrict operations on 4-bytes (even if you overflow, this should really not be an issue as we manipulate 4 bytes and not 8).

This will need to be thought about a little bit before trying to implement it, but this might be the correct way to go.

[Mesabloo]

This will no longer be needed anymore if there isn't a way to access lower bits of a register.
New platform-independent registers are described in this comment.
Closing for now, but will be reopened if this issue needs to be tackled again.