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> 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. For more options, visit https://groups.google.com/d/optout.
