On Thursday, 31 March 2022 at 18:40:52 UTC, deadalnix wrote:
> Honestly, I don't care if DMD forward the operation to something in druntime, that would at least allow me to have good codegen on LDC/GDC.

With LDC's support for inline LLVM IR (https://wiki.dlang.org/LDC_inline_IR), I think we can quite easily have a much better `core.int128` solution for LDC at least. Coupled with LLVM's compiler-rt builtins library, which should provide performant library fallbacks for targets with limited hardware support. So that a druntime `Cent` solution should be on-par with clang's `__int128`.

The existing generic software implementation is still useful for CTFE.

On Thursday, 31 March 2022 at 22:30:48 UTC, kinke wrote:
> On Thursday, 31 March 2022 at 18:40:52 UTC, deadalnix wrote:
>> Honestly, I don't care if DMD forward the operation to something in druntime, that would at least allow me to have good codegen on LDC/GDC.
>
> With LDC's support for inline LLVM IR (https://wiki.dlang.org/LDC_inline_IR), I think we can quite easily have a much better `core.int128` solution for LDC at least. Coupled with LLVM's compiler-rt builtins library, which should provide performant library fallbacks for targets with limited hardware support. So that a druntime `Cent` solution should be on-par with clang's `__int128`.
>
> The existing generic software implementation is still useful for CTFE.

It's still quite ugly compared to just implementing cent properly e.g. lack of VRP and implicit conversions make the library approach a bit meh.

On Thursday, 31 March 2022 at 22:35:46 UTC, max haughton wrote:
> It's still quite ugly compared to just implementing cent properly e.g. lack of VRP and implicit conversions make the library approach a bit meh.

There's another advantage (besides the main one - not having to touch the frontend at all) - it's not restricted to 128 bits and *could* thus be a template for integers with N bits. I doubt VRP and implicit conversions are of high priority for the presumably few specialized usages of huge integers.

On Thursday, 31 March 2022 at 22:43:27 UTC, kinke wrote:
> On Thursday, 31 March 2022 at 22:35:46 UTC, max haughton wrote:
>> It's still quite ugly compared to just implementing cent properly e.g. lack of VRP and implicit conversions make the library approach a bit meh.
>
> There's another advantage (besides the main one - not having to touch the frontend at all) - it's not restricted to 128 bits and *could* thus be a template for integers with N bits. I doubt VRP and implicit conversions are of high priority for the presumably few specialized usages of huge integers.

The few times I have needed wide arithmetic in D, it not being available has been irritating, having it be available but as a weird library feature is just goading.

e.g. Being able to call 128bit functions with narrower types without having to inject Cent(xyz) everywhere is not a small thing.

On 3/31/2022 11:40 AM, deadalnix wrote:
> So now that you just killed the library solution by having the compiler specially recognize it, can we have cent/ucent?

No, because a great deal of the compiler internals would have to be redone for it. The compiler will also slow down as a result. (The internals all depend on integral types being able to accommodate the largest integral type.)

> Honestly, I don't care if DMD forward the operation to something in druntime, that would at least allow me to have good codegen on LDC/GDC.

I didn't kill the library solution. 'mul' being specially recognized by the compiler does not change its utility.

On 3/31/2022 3:35 PM, max haughton wrote:
> It's still quite ugly compared to just implementing cent properly e.g. lack of VRP and implicit conversions make the library approach a bit meh.

There are very few uses for a 128 bit type, so all the conveniences are not particularly necessary.

On Friday, 1 April 2022 at 02:41:58 UTC, Walter Bright wrote:
> On 3/31/2022 3:35 PM, max haughton wrote:
>> It's still quite ugly compared to just implementing cent properly e.g. lack of VRP and implicit conversions make the library approach a bit meh.
>
> There are very few uses for a 128 bit type, so all the conveniences are not particularly necessary.

That is a non sequitur statement Walter.

On 01/04/2022 9:18 AM, Quirin Schroll wrote:
> At some point, it’s going to be easier to make those types `__traits(signed, 128)`, `__traits(unsigned, 256)`, `__traits(signed, 512)` and so on, plus some `alias ducent = __traits(signed, 256)` in object.d instead of arguing where the right limit is.

This is something I have long since considered.

While dmd may not have been designed for this, it is my belief that this is the only way forward for built in types.

As hardware changes over the next hundred years, this will be a major win for whoever does it this way.