On Monday, February 6, 2017 at 3:55:35 AM UTC+8, T L wrote: > > > > 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> 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. >> >> >> > 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 >> > > Thanks! I think I almost get it. > > In short, when structs and slices are used as the non-first fields of > other structs, > then the struct and slice fields may be not 64bit aligned on 32bit OSes. > > But what about arrays? Can the first word in an allocated array be relied > upon to be 64-bit aligned? > > In fact, I still have another question needs to be clarify: what does the "word" in "The first word in a global variable or in an allocated struct or slice" mean? A field with the same length with int values?
-- 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.
