proposal: runtime: add AlignedN types that can be used to increase alignment

[ianlancetaylor]

The sync/atomic packages have this in the docs in the "Bugs" section: "On both ARM and x86-32, it is the caller's responsibility to arrange for 64-bit alignment of 64-bit words accessed atomically. The first word in a global variable or in an allocated struct or slice can be relied upon to be 64-bit aligned." This makes it difficult to use atomic operations in types that may not necessarily be at the beginning of an allocated struct or slice. For example, sync.WaitGroup does this:

	// 64-bit value: high 32 bits are counter, low 32 bits are waiter count.
	// 64-bit atomic operations require 64-bit alignment, but 32-bit
	// compilers do not ensure it. So we allocate 12 bytes and then use
	// the aligned 8 bytes in them as state.
	state1 [12]byte

and this:

func (wg *WaitGroup) state() *uint64 {
	if uintptr(unsafe.Pointer(&wg.state1))%8 == 0 {
		return (*uint64)(unsafe.Pointer(&wg.state1))
	} else {
		return (*uint64)(unsafe.Pointer(&wg.state1[4]))
	}
}

Further, on x86 there are vector instructions that require alignment to 16 bytes, and there are even some instructions (e.g., vmovaps with VEC.256), that require 32 byte alignment. While those instructions are not currently generated by the gc compiler, one can easily imagine using them in assembler code, which will require the values to be appropriately aligned.

To permit programmers to force the desired alignment, I propose that we add new types to the runtime package: runtime.Aligned2, runtime.Aligned4, runtime.Aligned8, runtime.Aligned16, runtime.Aligned32, runtime.Aligned64, runtime.Aligned128. (We could also use bit values, giving us runtime.Aligned16 through runtime.Aligned1024, if that seems clearer.)

These types will be identical to the type struct{} except that they will have a the alignment implied by the name. This will make it possible to write a struct as

type vector struct {
    vals [16]byte
    _ runtime.Aligned16
}

and ensure that instances of this struct will always be aligned to a 16 byte boundary.

It will be possible to change sync.Waitgroup to be

type WaitGroup struct {
    noCopy noCopy
    _ runtime.Aligned8
    state uint64
    sema uint32
}

simplifying the code.

Although this functionality will not be used widely, it does provide a facility that we need today without requiring awkward workarounds. The drawback is the addition of a new concept to the runtime, though I think it is fairly clear to those people who need to use it.

Another complexity is that we will have to decide whether the size of a value is always a multiple of the alignment of the value. Currently that is the case. It would not be the case for the runtime.AlignedN values. Should it be the case for any struct that contains a field with one of those types? If the size of a value is not always a multiple of the alignment, we will have to modify the memory allocator to support that concept. I don't think that will be particularly difficult, but I haven't really looked.

[josharian]

A few minor comments:

• If we do this, we should probably do go/types: add GCSizes #17586 too. It's not cmd/vet that relies on go/types for information about what cmd/compile will do alignment-wise. Another example is wasted.
• Your struct vector above will have a byte of padding at the end to avoid GC problems. You probably want the struct{} field as the first field. And we'll want to carefully document that recommendation. I mention this only because if you missed this detail, others definitely will.
• This could also be done with a //go: annotation on the type. We already have other //go: annotations on types. Don't panic. I'm not suggesting we do this. (Even the mere mention of annotations tends to raise banshee-level howling.) But it does raise the general question about when and why to use magic embedded types vs annotations vs perhaps some other general mechanism that doesn't exist yet.

[ianlancetaylor]

It's true that that we do have go:nointerface and go:notinheap annotations on types, but neither is documented and the latter is clearly only for the runtime. I suppose my general reaction to support //go: annotations on types can be summed up as https://www.youtube.com/watch?v=hulm_T_xnwY .

[cespare]

@ianlancetaylor when you wrote

(We could also use runtime.Aligned16, etc., if that seems clearer.)

I don't see how this differs from the previous sentence.

[ianlancetaylor]

@cespare I meant to imply using bit values rather than byte values. Updated original comment to clarify. Those names would mean that the AlignedN names would correspond to intN names.

[rsc]

I agree we should fix this problem. I am less certain about how to fix it. Perhaps to start we should just align 64-bit integers to 64-bit addresses on 32-bit platforms. It's called out in sync/atomic because it's basically a bug on our side, one that we've just not fixed.

The solution proposed here essentially assumes the compiler will not reorder fields, at least not if these tags are present. I don't think we've fully closed the door on that (#10014). In that issue (two years ago), I argued that it is important for the programmer to have control over locality, so wholesale reordering of fields is not great (for example, sort by size and then lay out would give optimal packing but I think be too invasive).

At the same time, I am getting tired of looking for uint32-sized or bool-sized holes when adding fields to existing structs, and even more I am getting tired of being forced to choose between "understandable struct definition" and "small-in-memory struct definition". I do wonder if the compiler should be able by default to sift individual small fields up into gaps that would otherwise go unfilled, but not otherwise reorder the definitions. This is getting off-topic for this issue, except that any such scheme would need an override annotation for cgo and so that might give a mechanism for expressing alignment as well; of course any reordering would need to keep alignment in mind. I don't have any good ideas.

Also not every variable that needs alignment is a field in a struct. I'm not sure what to do about that either. Code might declare 'var x [16]byte' and want to pass it to something that requires 16-byte alignment, for example. Maybe that's getting too far ahead of ourselves, but it's worth keeping in mind.

I had hoped that alignment would be a property of a type, not a specific declaration. Are there cases where that's not tenable?

[mdempsky]

runtime.AlignedCache (which could just alias an appropriate AlignedN type) would help address #19025.

[ianlancetaylor]

I did not mean to imply that this approach meant that the compiler could not reorder fields. The language spec does not state that the alignment of one field in a struct implies anything at all about the alignment of subsequent fields in the struct. I envision any uses of this as being of the form

type Vec struct {
    _ runtime.Aligned16
    b [16]byte
}

Here we know that any instance of Vec is aligned to a 16-byte boundary.

I agree that alignment should be a property of a type, and I believe that that satisfies all alignment needs in Go. The question is how you specify that alignment, and whether it can be done without using a magic comment. This proposal is one approach: in effect, you can only specify the alignment of struct types, and you do so by adding a field of type runtime.AlignedN.

For comparison, in C (with GCC extensions) you specify alignment of a type by writing

typedef T ... __attribute__((aligned(n)));

You can also specify alignment of a specific variable in the same way. Or, you can implement alignment for a specific memory allocation by using memalign or posix_memalign (since C's memory allocator does not understand types, it is generally necessary to use these functions when allocating memory for an aligned type).

Clearly for Go it would be nicer to be able to declare the alignment of any type, rather than this proposal which in effect only permits you to declare the alignment of a struct. If we can figure out a way to do that, we should. But I'd really rather not do it via a magic comment.

[minux]

For sync/atomic, the biggest problem is usually not the alignment of the whole structure (because we have at least 8 byte alignment on struct larger than 8 byte), but ensuring that the next uint64 will be aligned correctly within the struct. A nice solution is to just increase alignment of 64-bit types on 32-bit architectures. For vectors, I think once we figure out how to use SIMD intrinsics, we will have types of 128-bit, 256-bit and 512-bit alignment.

[ianlancetaylor]

For sync/atomic, the biggest problem is usually not the alignment of the
whole structure (because we have at least 8 byte alignment on struct larger
than 8 byte), but ensuring that the next uint64 will be aligned correctly
within the struct.

Yes, understood. With this proposal you write "the next uint64" as a field of type alignedUint64, a struct defined as

type alignedUint64 struct {
    _ runtime.Aligned8
    v uint64
}

Vectors and sync/atomic are not the only uses of aligned types, so I think a more general solution would be a good idea if we can find one.

[cespare]

Here's a slight variation on the original proposal:

• Add runtime.Align2, ... runtime.Align128. (Note: "align", not "aligned")
• These are just like struct{}, except that if a runtime.AlignN, is used as a struct field, it specifies the alignment of the following field (in declared order).
• If a runtime.AlignN is declared as the last struct field, it specifies the alignment of the entire struct.

This gets to @minux's point about aligning particular struct fields. You could even use multiple AlignNs to align multiple fields in a single struct.

(AlignN is more like a magic comment than AlignedN is, but at least it isn't a comment.)

[rsc]

@ianlancetaylor Thanks for the clarification. I was slightly confused by the fact that in your original post 'struct vector' (really should be 'type vector struct') puts the alignment after the field, not before.

[minux]

On Feb 13, 2017 7:46 PM, "Caleb Spare" ***@***.***> wrote: Here's a slight variation on the original proposal: - Add runtime.Align2, ... runtime.Align128. (Note: "align", not "aligned") - These are just like struct{}, except that if a runtime.AlignN, is used as a struct field, it specifies the alignment of the *following* field (in declared order). - If a runtime.AlignN is declared as the last struct field, it specifies the alignment of the entire struct.

I think any AlignN will set the alignment for the whole structure. The logic is this: In order to ensure N byte alignment for a particular field, we must first ensure at least N byte alignment for the whole structure and then make sure the field has N byte aligned offset within the structure. I understand this proposal diverges from existing C convention, but I think it's more intuitive to the programmer. And we can also add a magical AlignCacheLine type to force at least cache line alignment in order to reduce false sharing (i think this is better than #19025). In order to not make the types too magical from the language specification's perspective, I suggest that we make them like this: type alignedbyte byte // the only magical and unexported type, only allowed as underlying type of an array, the resulting array has the alignment as the size of the array type aligned16 [16]alignedbyte // a 16-byte aligned type which takes 16-byte of space. type Align16 [0]aligned16 // zero size, can be embedded into other structs to force alignment of the next field (and also the whole structure) This takes advantage of recently clarified spec #18950, regarding alignment of [0]T.

[josharian]

If a runtime.AlignN is declared as the last struct field, it specifies the alignment of the entire struct.

Zero-sized final fields cause cmd/compile to insert a padding byte at the end. I imagine that is unacceptable in many of the cases for which increasing alignment is important.

[rsc]

As Minux pointed out (hard to tell with the Github-mangling of the email reply), AlignN declared anywhere would end up specifying a min alignment for the entire struct, since a struct can't have alignment less than any of its fields.

[josharian]

Thanks, Russ, I missed that.

Clever, Minux. Seems like it might be worth accepting it is a language change and defining unsafe.AlignedByte and letting folks take it from there.

[ianlancetaylor]

alignedbyte is clever but I'm a little uncomfortable with the idea that [13]alignedbyte has an alignment requirement of 13 bytes.

[josharian]

Perhaps it could specify a minimum alignment, and compilers could choose to round up to the nearest power of two.

[cespare]

Regarding Minux's idea:

type Align16 [0]aligned16 // zero size, can be embedded into other structs
to force alignment of the next field (and also the whole structure)

To clarify, isn't there "magic" required to guarantee this relationship with the next field (same as in my AlignN version), if the compiler can reorder fields?

[minux]

The reason my original comment didn't export the alignedbyte type is because I only intend the runtime package to instantiate power-of-two sized array of it and then expose zero sized array of those types. I don't think we need to fully expose the magical alignedbyte type to the user (as a language extension.)

[rsc]

@josharian "minimum alignment" is not a well-defined concept unless the space of possible requests are all multiples or divisors of each others. A multiple of 16 is not a multiple of 13.

I tend to agree with Ian that alignedbyte is a little too much rope.

[minux]

I think the compiler definitely cannot reorder arbitrary structures. Perhaps we can embed a unsafe.PackedStruct to signify that the compiler can rearrange a struct, but I still think packing a struct is better done by another program, not automatic by the compiler. One question for the runtime.AlignN idea: could it be used to reduce the alignment? I.e. can it be used to pack a struct? type packed struct { // size 5 (instead of 8) uint8 _ runtime.Align1 uint32 // at offset 1 (instead of 4 and leave 3 byte padding) } Packing a struct is an occasionally requested feature (and it will actually help cgo w.r.t. complex types), but supporting that on some architectures means non-atomic accesses to non-naturally-aligned fields.

[josharian]

Ack.

The thing I am struggling with is that once you start introducing magic, it is unclear which the right magic is. A magic field type in package runtime? A comment-based type annotation? An interpreted field tag (or type tag)? A magic interface in package runtime (check whether a type has an Aligned2 method)?

This does feel a bit like a language change, though, and unsafe does seem like the right home for manually messing with alignments. Maybe there's an alternative unsafe formation that provides less rope? Here's a terrible idea to start: unsafe.AlignedShift: [n]unsafe.AlignedShift has alignment 1<<n. :)

[rsc]

I think the compiler definitely cannot reorder arbitrary structures.

What you think is only a little interesting; telling us why is much more interesting.

Perhaps we can embed a unsafe.PackedStruct to signify that the compiler can rearrange a struct, but I still think packing a struct is better done by another program, not automatic by the compiler.

That's fine for structs that people don't look at. What bothers me most about packing structs explicitly (by hand or with a program) is that doing so rewrites the source code to be less readable.

[bcmills]

Allowing the compiler to reorder structures would be tricky: we may need to distinguish between unoptimized layouts (which the compiler should obviously fix) and hand-optimized layouts.

If the author has intentionally adjusted cache-line locality or packed the struct to match a kernel or C data structure, how do we tell the compiler not to break that?

[rsc]

@bcmills, struct field reordering is #10014. When I mentioned it above I wrote:

This is getting off-topic for this issue, except that any such scheme would need an override annotation for cgo and so that might give a mechanism for expressing alignment as well.

[minux]

@rsc, it seems you used to oppose the idea of compiler reordering the fields. why you come to think that field reordering is beneficial now? #10014 (comment) And I still agree with your comment that packing the struct is solving the 1970 problem, and the 2010 problem can't be solved by the compiler, at least not alone.

[bcmills]

I would guess that most uses of alignment fall into one of two categories:

1. Passing a pointer to an unexported field to an atomic function.
2. Passing a struct to a C function (via cgo or a syscall).

We normally let the compiler figure out details of allocation and layout. Perhaps we could do the same for alignment most of the time.

We could do something akin to escape analysis to see which fields need to be aligned:

• If a pointer to a field is passed as a function parameter that requires a particular alignment, then both the field and the struct require at least that alignment. Pointers passed to functions in package atomic must be aligned to their element size.
• If a pointer to a field or struct is passed to a cgo function call, syscall, or converted to an unsafe.Pointer which may be passed to a cgo function call or syscall, then the field and the struct require C-compatible alignment.

For the few remaining cases (are there any?), perhaps we could add a no-op function call (akin to runtime.KeepAlive):

package runtime

// Align marks its argument as requiring the given alignment.
// The ptr argument must be a pointer to a variable of a struct type,
// or a pointer to a field on a variable of a struct type. 
// The alignment argument must be a compile-time constant.
func Align(ptr interface{}, alignment int)

The only situation I'm aware of that would require explicit calls to Align would be if a pointer is allocated and returned from a function in one package but the alignment constraints occur only in the calling package. I cannot think of any examples of such usage at the moment.

[josharian]

@bcmills a remaining case: argument to user-written assembly routine using vector instructions. (Minux mentioned this above too.)

[gopherbot]

Change https://golang.org/cl/308971 mentions this issue: cmd/compile: add internal/align package for runtime

[rogpeppe]

One other thought that's probably horrible, but I'll leave it here anyway: how about making runtime.Aligned work by using the size of the array that it's part of (Aligned would be zero sized) ?

type WaitGroup struct {
    _ [8]runtime.Aligned
    state uint64
    sema uint32
}

That allows any alignment to be specified without introducing a zillion new types.

Edit: I see that's pretty similar to this.

For the [17]runtime.Aligned case, maybe it's reasonable to give the compiler the freedom to arbitrarily increase the alignment if it's not compatible with hardware constraints. So on a machine that didn't allow unaligned word access, it could round up to the nearest word-size multiple.

[mdempsky]

how about making runtime.Aligned work by using the size of the array that it's part of (Aligned would be zero sized) ?

This is how internal/align.elemT works in https://golang.org/cl/308971.

[yuseferi]

sounds like an interesting topic and someone gave a talk at GopherConf Eu 2023,
any update on this proposal?

[rip-create-your-account]

I have a use case that I don't see mentioned here. I'm working on a concurrent hash map and it requires a guaranteed alignment of 64 for the buckets that it allocates internally. I'm storing these buckets in a huge array where a bucket pointer is stored together with a [0, 64) 6-bit integer. I need guaranteed alignment so that I can pack the 6-bit integer into the pointer value like so:

// unsafe.Pointer value is legal as long as it points _somewhere_ into the object. Because
// our buckets always have sizeof >= 64B (and alignment of 64) it means that we can pack the
// 6-bit value into the lowest 6 bits so that the resulting pointer will continue to point into
// the original allocated object.
packed := unsafe.Add(unsafe.Pointer(bucket), smallInt)
atomic.StorePointer(&arrayElement.ptr, packed)

// and unpacking
packed := atomic.LoadPointer(&arrayElement.ptr)
bucket := (*Bucket)(unsafe.Pointer(uintptr(packed) &^ 0b11_1111))
smallInt := uint64(uintptr(packed) & 0b11_1111)

For my benchmark cases the allocator just happens to give the buckets alignment of 64 but I really need the guarantee as this packing produces a very measurable performance boost on multiple metrics compared to storing both values in their individual fields. I would like to see this proposal advance.

[G-M-twostay]

I have a use case where I wish to use the last bit of the address to generic struct for pointer tagging. The structs are stored in an array and I will use uintptr to array elements to perform pointer tagging.

type SometimesAligned[T constraints.Unsigned] struct{
    a,b,c T //constraints.Unsigned just limit to all unsigned int types.
}

Now SometimesAligned[byte] is the only thing that's aligned to 1 byte and thus isn't safe to use pointer tagging. Using

type Aligned0[T constraints.Unsigned] struct{
    a,b,c T 
    _ uint16
}

gives me 2 bytes alignment but will introduce unnecessary wasted space. It'll waste even more spaces on larger types.

type Aligned1 struct{
    values [2]uint16
}

only wastes 1 byte of space and essentially has the same capability as SometimesAlgined[byte]. However, it's hard to make this generic.

I wish to avoid the wasted spaces as much as possible while keeping the generic capability because these structs can be created in large numbers in arrays.

[randall77]

Does a _ [0]uint16 field work for you?

[MatthiasKunnen]

I'm interested in this for the purpose of mapping shared memory (named memory in Windows, memory mapped file in Linux). Being able to map structs to memory requires alignment.

This is a snippet of what I am using at moment:

type Header struct {
	Status [4]byte // UTF-8 string

	Version uint32

	Revision uint32

	// The unix time when the last update to the data occurred.
	// Get int using GetLastUpdate.
	LastUpdate [8]byte

	// Offset of the Sensor section from beginning of Header.
	Offset uint32
}
func (info Header) GetLastUpdate() int64 {
	return int64(binary.LittleEndian.Uint64(info.LastUpdate[:]))
}

uint32 is aligned at the moment but this might change, uint64 is not, it has padding, so I'm using [8]byte.

[G-M-twostay]

Does a _ [0]uint16 field work for you?

Thank you. It looks like

type Aligned[T constraints.Unsigned] struct{
    _ [0]uint16
    a,b,c T
}

works ideally, but I kind of feel like it's a bit unintuitive.

[randall77]

@G-M-twostay If this proposal is accepted, you will be able to write _ runtime.Aligned2 instead.

[randall77]

@MatthiasKunnen Are you saying your LastUpdate field contains a 64-bit integer, but is not 64-bit aligned? Are you trying to match a native Windows API that behaves like that? Or is there another reason you want non-64-bit aligned 64-bit integers?
This proposal won't help that situation (if I'm interpreting your situation correctly). It will only increase alignment, not decrease it.

[MatthiasKunnen]

@randall77 LastUpdate contains a 64-bit integer but using uint64 as the type takes more space than 64 bits. It was a while ago but I believe this was due to padding or something the compiler does for optimization.

This is a program that shares data by sharing a part of its memory that is packed according to a documented structure.

In essence, I'm trying to mirror C# code like this:

[StructLayout(LayoutKind.Sequential, Pack = 1, CharSet = CharSet.Ansi)]
public struct SharedMemory {
    public UInt32 version;
    public UInt8 rev; // This must be byte in Go because, I believe, uint8 still takes 32 bits
    public long poll_time; // This must be [8]byte in Go because uint64 takes more than 64 bits
};

[rip-create-your-account]

Not to turn this issue to my personal blog but I have to report my ever increasing thirst for this feature. My concurrent hash map has a len atomic.Int64 field and as one would expect it's getting hammered by all CPU cores on the insert path causing false-sharing and whatever else on the other fields. Manually adding padding so that the field is on its own 128-byte chunk like the following has quite the impact on performance.

type Map[K comparable, V any] struct {
	//...
	pad [128 - 40]byte
	len atomic.Int64
}

old: BenchmarkInsert/size=100000-8 40.77 ns/insert
new: BenchmarkInsert/size=100000-8 27.99 ns/insert

I have zero (0, nil) interest in manually maintaining the correct amount of padding. So I need runtime.Aligned64 to make the map work correctly and runtime.AlignedCacheLine to keep it simple and fast.

[randall77]

@MatthiasKunnen: So it is the Pack=1 part of that C# declaration that is not aligning poll_time to 64-bit boundaries?
In that case, I think the way you are doing it, with [8]byte, is really your only option. This proposal (or any other that I know of) will not help in that situation.

[MatthiasKunnen]

@randall77, apologies, I was using the wrong terminology. C# does not do any alignment with pack=1. Rather, it packs all fields as tightly as possible with no extra padding. Go does not do this in case of types such as uint64 and uint8. That being said, you are correct that this proposal will not help in this situation (I'm looking for padding decrease, not alignment increase) so I'll refrain from further comments to not derail the discussion. My previous comments can be minimized if desired.

[kostix]

I'm interested in this for the purpose of mapping shared memory (named memory in Windows, memory mapped file in Linux). Being able to map structs to memory requires alignment.

This is a snippet of what I am using at moment:

type Header struct {
	Status [4]byte // UTF-8 string

	Version uint32

	Revision uint32

	// The unix time when the last update to the data occurred.
	// Get int using GetLastUpdate.
	LastUpdate [8]byte

	// Offset of the Sensor section from beginning of Header.
	Offset uint32
}

<…>

uint32 is aligned at the moment but this might change, uint64 is not, it has padding, so I'm using [8]byte.
<…>
@randall77 LastUpdate contains a 64-bit integer but using uint64 as the type takes more space than 64 bits.
It was a while ago but I believe this was due to padding or something the compiler does for optimization.

Here's the reason: Go makes sure each field in a struct type is aligned using the field's type natural alignment.
If you look at your types, you'll see that Status [4]byte is 32-bit, which makes the next 32-bit-sized field, Version, be naturally aligned; since the next field, Revision is also 32-bit, it's still naturally aligned.
All these three fields take up 4×3=12 bytes, and if the next field, LastUpdate, were to be a 64-bit (8 byte) integer, it would not be naturally aligned "as is", and the compiler would stuff 4 bytes before to make up for 16 bytes preceding space in total, which is wholly divisible by 8 making the field be naturally aligned.

Since a single byte is always naturally aligned, using [8]byte instead of 64-bit integer does not make the compiler insert any padding before that field. This is why you see differences in type size in both cases.

This is a program that shares data by sharing a part of its memory that is packed according to a documented structure.

In essence, I'm trying to mirror C# code like this:

[StructLayout(LayoutKind.Sequential, Pack = 1, CharSet = CharSet.Ansi)]
public struct SharedMemory {
    public UInt32 version;
    public UInt8 rev; // This must be byte in Go because, I believe, uint8 still takes 32 bits
    public long poll_time; // This must be [8]byte in Go because uint64 takes more than 64 bits
};

While your desire is understandable, please note an important thing: some hardware architectures require memory loads and stores to be performed on addresses naturally aligned for the types ("sizes") of data they perform; basically, you cannot perform an (imaginary) machine instruction LOAD $ADDR -> %INT64_REG unless $ADDR is aligned on a 8-byte boundary; performing such an operation would make the CPU (!) generate an error at runtime.
I beleive this is the reason Go makes all fields in structs naturally aligned for their respective types.

x86, which is most probably the architecture you're using, does not have the above restriction: the instructions operating on unaligned memory pefrorm slower but do not fail (while I cannot present any proofs ATM, I also beleive x86 does even still preserve atomicity for such operations).

What I'm leading you to, is that if Go were to allow what you're after — that is, to have LastUpdate be a 64-bit integer not aligned naturally, — an attempt to read or modify it (by machive-level "integer sized" instructions the compiler would likely have generated for that) would fail on some architectures Go supports.

In other words, if Go would have something like #pragma pack(1) of some C compilers or that Pack = 1 of .NET's interop, your code would have needed to be guarded by build constraints making it only compilable on amd64 and 386. (And this also hints at that such a feature, if implemented, would need to somehow require the usage of unsafe as it can break the main guarantee provided by Go — that what its compiler generates, cannot be incorrect from the PoV of the target hardware.)

As you can see, at the moment reading that 64-bit field using something like encoding/binary.LittleEndian.Uint64 definitely looks unwieldy but is guaranteed to work on any H/W arch.

If you're 100% sure this code will only ever work on x86, you could write a helper function which would still read that memory as an integer using type-punning made possible by unsafe (basically take the address of the 1st byte of that [8]byte array, reinterpret it as a pointer to a 64-bit integer and dereference the result).

[MatthiasKunnen]

@kostix, thank you for this dive into the reasoning behind it. Very interesting and informative!