[swift-evolution] [Idea] A 128-bit unsigned integer value type

[Max Moiseev]

FWIW: here is the link to the prototype https://github.com/apple/swift/blob/master/test/Prototypes/Integers.swift.gyb

Max

> On May 25, 2016, at 3:53 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> on Sat May 21 2016, Károly Lőrentey <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> On 2016-05-17 14:30:36 +0000, Muse M via swift-evolution said:
>> 
>>> Most programming languages does have 128-bit of type except Swift.
>> 
>> I don't think there is huge demand for a full-blown Int128 type in the
>> standard library, but it would be nice to have double-width
>> multiplication & division methods in Swift's existing integer types. I
>> assume LLVM has intrinsics for this that compile down to single
>> instructions on x86_64.
>> 
>> This would speed up some 64-bit fixed-point operations with 128-bit
>> temporaries (such as Mach timestamp scaling arithmetic) and allow pure
>> Swift arbitrary-precision integer packages to provide faster
>> operations.
>> 
>> I currently need to emulate full-width multiplication/division with
>> code such as this:
>> 
>> https://github.com/lorentey/BigInt/blob/master/Sources/BigDigit.swift#L102-L177 
>> 
>> A 128/64=64 full-width division done this way requires 2 single-width
>> divisions and 6 multiplications. I'd love to replace this with a
>> single full-width x86 DIV instruction.
> 
> One reason we don't have Int128 everywhere is that we don't currently
> have the necessary primitives on 32-bit systems.
> 
> However, when the integers protocol proposal that Max Moiseev is working on
> comes out, it will include an implementation of a 
> 
>  DoublePrecision<T:Integer>
> 
> either as public API or in the tests (I forget which).  The intention is
> that on 32-bit platforms we can eventually define Int128 as a typealias
> for DoublePrecision<Int64>.  We can also introduce Int256, for which I
> know there is an audience.
> 
> -- 
> -Dave
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160526/0e98b9ba/attachment.html>