| |
![Iain Buclaw's Gravatar profile Gravatar of Iain Buclaw](//www.gravatar.com/avatar/17bbd0ceb5389a8803c04834f286731b?d=identicon&s=32) | Posted by Iain Buclaw in reply to deadalnix | Permalink Reply |
|
Iain Buclaw ![Iain Buclaw's Gravatar profile Gravatar of Iain Buclaw](//www.gravatar.com/avatar/17bbd0ceb5389a8803c04834f286731b?d=identicon&s=80)
Posted in reply to deadalnix
| On Thursday, 31 March 2022 at 18:40:52 UTC, deadalnix wrote:
> On Thursday, 31 March 2022 at 06:31:32 UTC, Walter Bright wrote:
>> You see a similar thing when 32 bit compilation does 64 bit arithmetic:
>>
>> [...]
>>
>> So, yeah, supporting 128 bit arithmetic in the codegen has significant advantages. 3 multiplies and 2 adds.
>>
>> Having the compiler recognize the `mul` function as a builtin would enable this code gen for 128 bits.
>
> So now that you just killed the library solution by having the compiler specially recognize it, can we have cent/ucent?
>
> 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.
We can do the same as complex numbers here.
enum __c__int128 : core.int128.Cent;
enum __c__uint128 : core.int128.Cent;
Later, when cent/ucent have been dropped as keywords.
alias cent = __c__int128;
alias ucent = __c__uint128;
|