int and uint are the same size per the spec, so there is nothing to do (no sign extension and no subsequent truncation).
What happens in other languages is largely irrelevant here (golang- nuts). On Sat, 2018-11-24 at 18:16 -0600, robert engels wrote: > This maybe true for Go, but not necessarily all languages. It might > be implemented as > > result = original & 0x7FFFFFFF (for 32 bit int to uint) > > it depends on how the language specifies the conversion will occur. > > That being said, in Go the spec says: > For the conversion of non-constant numeric values, the following > rules apply: > > When converting between integer types, if the value is a signed > integer, it is sign extended to implicit infinite precision; > otherwise it is zero extended. It is then truncated to fit in the > result type's size. For example, if v := uint16(0x10F0), then > uint32(int8(v)) == 0xFFFFFFF0. The conversion always yields a valid > value; there is no indication of overflow. > the compiler and platform might actually need to add the AND as > specified above, or other sign extension operations… on most > platforms, probably not since int and uint would be the same size. > The ambiguity with the above spec, is that a negative number will > become positive, or visa-verse - even though this is not technically > ‘overflow’, at least IMO. > > > > > On Nov 24, 2018, at 5:49 PM, 'Keith Randall' via golang-nuts <golan > > g-n...@googlegroups.com> wrote: > > > > int<->uint conversions should never generate any machine code. They > > are free. > > > > On Saturday, November 24, 2018 at 10:55:50 AM UTC-8, Andy Balholm > > wrote: > > There is nothing in the language spec that guarantees anything > > about performance. But if logic tells you that it should be a no- > > op, and examination of the generated code shows you that it is a > > no-op in the cases you tested, you can safely assume that it is not > > going to be an issue for your program’s performance. > > > > Andy > > > > > > > > On Nov 24, 2018, at 8:45 AM, Ugorji Nwoke <ugo...@gmail.com <>> > > > wrote: > > > > > > Thanks so much Silviu. I love this tool - I had seen it before, > > > but didn't realize it also supported go language. Thanks so much > > > for bringing it up - it should help me do more investigation on > > > my own faster. > > > > > > I used it to compare the asm output, and I got the same thing as > > > when I did > > > go build -gcflags "-S" num_conversion.go > > > > > > i.e. it leads me to conclude, as I suspected, that conversion > > > from int to uint is free (no-op at runtime). > > > > > > However, I get concerned that my proof may be insufficient, or > > > there may be other reason why the asm looks same, and that is why > > > I wanted a definitive answer from someone familiar with the > > > internals. > > > > > > > > > On Saturday, November 24, 2018 at 11:28:43 AM UTC-5, Silviu > > > Capota Mera wrote: > > > A very nice tool from Matt Godbolt (and team of volunteers): http > > > s://godbolt.org/z/4nt5cJ <https://godbolt.org/z/4nt5cJ> > > > > > > You can switch compiler version (e.g. Go 1.4, 1.7, 1.9, 1.11, > > > tip, etc) and/or gccgo, take a look at variations, etc > > > > > > On Saturday, 24 November 2018 11:07:51 UTC-5, Jan Mercl wrote: > > > On Sat, Nov 24, 2018 at 4:31 PM Ugorji Nwoke <ugo...@gmail.com > > > <>> wrote: > > > > > > > > > > > Jan, you and I have the same understanding i.e. float <-> int > > > > is obviously non-free, but I can't think of why int <-> uint > > > > will not be free. However, I want someone with knowledge of > > > > the > > > > compiler/runtime/codegeneration/SSA internals that can give me > > > a definitive answer. > > > > > > Any correct compiler is an implementation of the language > > > specification. From the language specification it follows that > > > the compiler _may_ check that - for example - 42 != 314 or 278 == > > > 278 while performing the 'uint' <-> 'int" conversion. It may also > > > try to factor M4170639287. The question is why to do so when > > > nothing of that is mandated by the language specification for a > > > correct implementation? > > > > > > The next reasonable step is to assume Occam's razor is a thing. > > > > > > -- > > > -j > > > > > > > > > -- > > > 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...@googlegroups.com <>. > > > For more options, visit https://groups.google.com/d/optout > > > <https://groups.google.com/d/optout>. > > > > -- > > 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 <mailto:g > > olang-nuts+unsubscr...@googlegroups.com>. > > For more options, visit https://groups.google.com/d/optout > > <https://groups.google.com/d/optout>. -- CRICOS provider code 00123M -- 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.
