And as one overly anal person already pointed out - it is complement. > On Nov 24, 2018, at 6:50 PM, robert engels <reng...@ix.netcom.com> wrote: > > Although by the spec stating - sign extended - they are limiting Go to work > on 2’s compliment platforms… > >> On Nov 24, 2018, at 6:48 PM, robert engels <reng...@ix.netcom.com >> <mailto:reng...@ix.netcom.com>> wrote: >> >> 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 >>> <mailto: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 <mailto: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 >>>>>> <http://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 >> <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 > <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.
