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 > <golang-nuts@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): >> https://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:golang-nuts+unsubscr...@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. For more options, visit https://groups.google.com/d/optout.
