On Monday, February 6, 2017 at 3:14:22 AM UTC+8, Ian Lance Taylor wrote: > > On Sun, Feb 5, 2017 at 10:52 AM, T L <tapi...@gmail.com <javascript:>> > wrote: > > Ian, thanks for the answers. > > > > But I still not very confirm on many points. > > > > Up to now, there are two places mention the alignments in Go. > > > > The first is in the end of Go spec: > > > > > > Size and alignment guarantees > > > > For the numeric types, the following sizes are guaranteed: > > > > type size in bytes > > > > byte, uint8, int8 1 > > uint16, int16 2 > > uint32, int32, float32 4 > > uint64, int64, float64, complex64 8 > > complex128 16 > > > > The following minimal alignment properties are guaranteed: > > > > For a variable x of any type: unsafe.Alignof(x) is at least 1. > > For a variable x of struct type: unsafe.Alignof(x) is the largest of all > the > > values unsafe.Alignof(x.f) for each field f of x, but at least 1. > > For a variable x of array type: unsafe.Alignof(x) is the same as > > unsafe.Alignof(x[0]), but at least 1. > > > > A struct or array type has size zero if it contains no fields (or > elements, > > respectively) that have a size greater than zero. Two distinct zero-size > > variables may have the same address in memory. > > > > > > The second is at the end of sync/atomic docs: > > > > > > On x86-32, the 64-bit functions use instructions unavailable before the > > Pentium MMX. > > > > On non-Linux ARM, the 64-bit functions use instructions unavailable > before > > the ARMv6k core. > > > > 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. > > > > > > I feel the two are not enough to remove all my confusions. > > > > So could you help me remove the following confusions: > > > > > > 1. What does the "allocated struct or slice" mean? > > > > > > Currently, I think it means the structs or slices created by new, or the > > structs or slices escape to heap. > > > > Is my understanding right? > > Those cases are "allocated struct or slice," yes. The phrase also > includes variables defined with a struct or slice type. > > > > 2. Are local 8-bytes variables 64bit aligned on 32bit OSes? > > > > > > I found there are many usages of the 64bit functions of atomic package > being > > used on local 8-bytes variables in go source. > > > > So I think the answer is yes. Right? > > Yes. > > I installed a 32bit VM and found that local int64 and [N]int64 variables are not guaranteed to be 64bit aligned. But the magic is, if the local int64 variables are passed to atomic 64bit functions, then they become 64bit aligned for sure. Quite magic.
It looks when local int64 variables are escaped to heap if their addresses are passed to atomic 64bit functions. And it looks 64bit words allocated on heap are always 64bit aligned, even on 32bit OSes. > > > 3. Are expvar.Int and expvar.Float safe to be embedded in other structs > on > > 32bit OSes? > > > > > > I think the answer is no. Is my opinion right? > > You could embed them as the first field of a struct (if you were then > careful to not embed that struct, (except as the first field)). > > It would not be portable to embed them as anything other than the first > field. > > I think this is problematic, and it would be nice to figure out a way to > fix it. > > Ian > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
