I realized what my mistake was after reading the spec further, so I'll
put a follow-up here for archival purposes:
Given a tagged union is a structure with a tag, the pointer to it points
to the said tag. So, in my example, `y` points to the unsigned 32 bit
integer with the union's tag, whereas `z` points to the next cell with
the contents of the union.
And even in the cases where padding is present, the pointer still points
to the tag:
```
use fmt;
export fn main() void = {
let x: (u64 | []u8) = 42u64;
let y: nullable *(u64 | []u8) = &x;
// padding
let shift_m1 = (y: uintptr - size(u32): uintptr): *u32;
fmt::println(*shift_m1)!;
// tag of the tagged union
let shift_0 = (y: uintptr): *u32;
fmt::println(*shift_0)!;
// first half of the data
let shift_1 = (y: uintptr + size(u32): uintptr): *u32;
fmt::println(*shift_1)!;
// second half of the data
let shift_1 = (y: uintptr + 2 * size(u32): uintptr): *u32;
fmt::println(*shift_1)!;
};
```
By the way, we're currently partway through changing how tagged unions
with padding between the tag and the body are represented. The spec
currently describes one of the new ways, the compiler does the old
thing, and we're planning to end up doing a third thing. So take
anything you figure out there with somewhat of a grain of salt.
However, this code isn't correct. It's easier to think about this by
looking at how the tagged union would be represented as a struct, with y
always being a pointer to the start of the struct. Currently, it would
be represented by harec as
struct {
tag: u32,
padding: u32,
data: ...
}
The spec currently says
struct {
padding: u32,
tag: u32,
data: ...
}
And the eventual plan is to have padding after the tag for 8-aligned
members and no padding anywhere for 4-aligned members. Hope this helps
I see, thank You for the clarifications!
Given this, can I ask You about the pointer itself? Does the fact that
the struct for the tagged union can have padding before the tag mean,
that data about the tagged union is also stored with the pointer? (aka,
how does the pointer know wherever it needs to step over the padding or
not?) Maybe You can direct me to the place in the source code where the
pointers are handled, I am just having a hard time understanding which
part of the compiler does what.
P. S.
By the way, is appendix for the Hare spec work in progress or is it
available in another file, other than the main spec pdf?
On Fri Jan 20, 2023 at 3:51 PM UTC, KAAtheWise wrote:
> Given this, can I ask You about the pointer itself? Does the fact that> the struct for the tagged union can have padding before the tag mean,> that data about the tagged union is also stored with the pointer? (aka,> how does the pointer know wherever it needs to step over the padding or> not?) Maybe You can direct me to the place in the source code where the> pointers are handled, I am just having a hard time understanding which> part of the compiler does what.
The pointer doesn't know anything about the data it points to - the
relevant logic would be getting the tag from a tagged union, see
https://lists.sr.ht/~sircmpwn/hare-dev/patches/37664 for the version
that corresponds to what the spec says. Basically, the compiler always
knows the type of the tagged union at compile time, so it emits the
equivalent of either *(((&union: uintptr) + 4): *u32) or *(&union: *u32)
depending on the type.
> By the way, is appendix for the Hare spec work in progress or is it> available in another file, other than the main spec pdf?
The appendices haven't been written yet.
Thank You again for the explanation, I think I understand how it works
now.
And out of pure curiosity, what was the rationale behind switching
padding and tag for the original change, if any? The grouping of types
by alignment (the jfreymuth's proposal) works a bit differently. But
with the current setup, as I understand it, the compiler needs to
consider wherever the union alignment is 4 or 8 regardless of where the
padding goes.