That is only the case if the platform uses 2’s compliment signed numbers - which is almost certainly the case, but doesn’t have to be...
> On Nov 24, 2018, at 6:42 PM, Dan Kortschak <dan.kortsc...@adelaide.edu.au> > wrote: > > 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 <s://godbolt.org/z/4nt5cJ> >>>> <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 >>>> <http://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 >>>> <http://googlegroups.com/> <>. >>>> For more options, visit https://groups.google.com/d/optout >>>> <https://groups.google.com/d/optout> >>>> <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> <mailto:g >>> olang-nuts+unsubscr...@googlegroups.com >>> <mailto:olang-nuts+unsubscr...@googlegroups.com>>. >>> For more options, visit https://groups.google.com/d/optout >>> <https://groups.google.com/d/optout> >>> <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 > <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.
