www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - When will you implement cent and ucent?

reply Murilo <murilomiranda92 hotmail.com> writes:
I have been waiting for years now, can't you guys just add these 
2 types to the language?
Mar 25 2022
next sibling parent reply Adam Ruppe <destructionator gmail.com> writes:
What would you do with it? There's a number of alternatives 
available today depending what you need.
Mar 25 2022
next sibling parent reply Murilo <murilomiranda92 hotmail.com> writes:
On Friday, 25 March 2022 at 23:50:39 UTC, Adam Ruppe wrote:

 What would you do with it? There's a number of alternatives 
 available today depending what you need.


I would perform calculation with astronomical numbers and atomic 
precision.
Mar 25 2022
parent reply Era Scarecrow <rtcvb32 yahoo.com> writes:
On Saturday, 26 March 2022 at 04:02:18 UTC, Murilo wrote:

 I would perform calculation with astronomical numbers and 
 atomic precision.


  If you aren't sure what size of numbers you need, BigInt/BigNum 
would be better.

  If you need fractions, might be more interested in using GMP, as 
it will give you floating precision you want.

  https://gmplib.org/

  float/double/real (32/64/80) allow a very large range of rough 
values within ranges and are built in with the FPU.

  If you want a fixed int-type, then int/long/cent or others would 
be practical.

  So question, what doesn't BigInt do that you need cent/ucent for?
Mar 25 2022
parent reply Murilo <murilomiranda92 hotmail.com> writes:
On Saturday, 26 March 2022 at 06:53:32 UTC, Era Scarecrow wrote:

 On Saturday, 26 March 2022 at 04:02:18 UTC, Murilo wrote:

 I would perform calculation with astronomical numbers and 
 atomic precision.



  So question, what doesn't BigInt do that you need cent/ucent 
 for?


I figured BitInt would be slower because it works with strings, 
working with pure binary would be faster, if there was a cent and 
ucent type I would be able to do the math faster.
Mar 26 2022
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Mar 26, 2022 at 06:03:57PM +0000, Murilo via Digitalmars-d wrote:
[...]

 I figured BitInt would be slower because it works with strings,
 working with pure binary would be faster, if there was a cent and
 ucent type I would be able to do the math faster.


That is false.  BigInt works with arrays of ulongs, which is as binary
as you're gonna get.


T

-- 
Mediocrity has been pushed to extremes.
Mar 26 2022
next sibling parent Era Scarecrow <rtcvb32 yahoo.com> writes:
On Saturday, 26 March 2022 at 18:12:08 UTC, H. S. Teoh wrote:

 On Sat, Mar 26, 2022 at 06:03:57PM +0000, Murilo wrote: [...]

 I figured BitInt would be slower because it works with 
 strings, working with pure binary would be faster, if there 
 was a cent and ucent type I would be able to do the math 
 faster.


 That is false.  BigInt works with arrays of ulongs, which is as 
 binary as you're gonna get.


  It's been a while since we have been doing BCD (*Binary Coded 
decimals*) which are base-10, which 8bit computers and 
calculators use to put 2 digits in 1 byte. No, it's far faster to 
use the built-in larger binary types, rather than lowering to 1 
number at a time.

  My library was on par with BigInt in speed, unless you utilized 
all instruction sets during compiling; Then BigInt is actually a 
bit faster making use of a few extra feature sets i haven't coded 
to take advantage of yet. Trying to compile the data to test and 
write is annoying.

  Doing math purely based on string/text certainly can be done and 
may be easy to do, but will be slow and best for examples of 
infinite precision and not used for real-time applications.
Mar 26 2022
prev sibling parent reply Murilo <murilomiranda92 hotmail.com> writes:
On Saturday, 26 March 2022 at 18:12:08 UTC, H. S. Teoh wrote:

 On Sat, Mar 26, 2022 at 06:03:57PM +0000, Murilo via 
 Digitalmars-d wrote: [...]

 I figured BitInt would be slower because it works with 
 strings, working with pure binary would be faster, if there 
 was a cent and ucent type I would be able to do the math 
 faster.


 That is false.  BigInt works with arrays of ulongs, which is as 
 binary as you're gonna get.


 T


Thanks for clearing that up, I guess I'll just stick to BigInt 
then. I've used it to make a calculator that turns numbers into 
strings and does the math just like we do it with pen and paper, 
that way I can calculate decimals with perfect precision. It is 
able to do around 30k adds/subtracts per seconds, around 25k 
multiplys per second and around 5.5k divides per second with 
perfect precision of 20 decimal places.
Mar 27 2022
parent Sergey <kornburn yandex.ru> writes:
On Sunday, 27 March 2022 at 19:05:09 UTC, Murilo wrote:

 Thanks for clearing that up, I guess I'll just stick to BigInt 
 then. I've used it to make a calculator that turns numbers into 
 strings and does the math just like we do it with pen and 
 paper, that way I can calculate decimals with perfect 
 precision. It is able to do around 30k adds/subtracts per 
 seconds, around 25k multiplys per second and around 5.5k 
 divides per second with perfect precision of 20 decimal places.


There is no D implementation, but there is a good C library for 
POSIT
Some info could be found here: https://posithub.org/

Maybe will be useful for precise calculation
Mar 27 2022
prev sibling next sibling parent IGotD- <nise nise.com> writes:
On Friday, 25 March 2022 at 23:50:39 UTC, Adam Ruppe wrote:

 What would you do with it? There's a number of alternatives 
 available today depending what you need.
Mar 26 2022
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Friday, 25 March 2022 at 23:50:39 UTC, Adam Ruppe wrote:

 What would you do with it? There's a number of alternatives 
 available today depending what you need.


There is literally no way to implement a big number lib that'll 
optimize properly without and integer that is 2x what the machine 
supports. That means 128 bits on 64 bits machines. This is 
important for cryptography for instance.
Mar 28 2022
parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Monday, 28 March 2022 at 18:40:34 UTC, deadalnix wrote:

 On Friday, 25 March 2022 at 23:50:39 UTC, Adam Ruppe wrote:

 What would you do with it? There's a number of alternatives 
 available today depending what you need.


 There is literally no way to implement a big number lib


Murilo might not need a big number lib at all.

For astronomy, there's a good chance floating point will do the 
job.
Mar 29 2022
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Tuesday, 29 March 2022 at 12:13:31 UTC, Adam D Ruppe wrote:

 On Monday, 28 March 2022 at 18:40:34 UTC, deadalnix wrote:

 On Friday, 25 March 2022 at 23:50:39 UTC, Adam Ruppe wrote:

 What would you do with it? There's a number of alternatives 
 available today depending what you need.


 There is literally no way to implement a big number lib


 Murilo might not need a big number lib at all.

 For astronomy, there's a good chance floating point will do the 
 job.


That not going to work if you are comparing things that are 
extremely big with something that is extremely small here.

- Alex
Mar 29 2022
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Mar 29, 2022 at 01:58:46PM +0000, 12345swordy via Digitalmars-d wrote:

 On Tuesday, 29 March 2022 at 12:13:31 UTC, Adam D Ruppe wrote:


[...]

 Murilo might not need a big number lib at all.
 
 For astronomy, there's a good chance floating point will do the job.


 
 That not going to work if you are comparing things that are extremely
 big with something that is extremely small here.


[...]

I think you got that wrong, floating is precisely designed for such
comparisons. You can easily compare 1e+1000 with 1e-1000 without running
into problems.

Where you might run into problems is if you *add* (or subtract)
extremely small numbers from extremely big numbers. Or if you divide by
extremely small numbers. Or in general perform operations that mix
numbers of greatly unlike magnitudes.


T

-- 
Error: Keyboard not attached. Press F1 to continue. -- Yoon Ha Lee, CONLANG
Mar 29 2022
next sibling parent Abdulhaq <alynch4047 gmail.com> writes:
On Tuesday, 29 March 2022 at 15:23:45 UTC, H. S. Teoh wrote:

 On Tue, Mar 29, 2022 at 01:58:46PM +0000, 12345swordy via 
 Digitalmars-d wrote:

 On Tuesday, 29 March 2022 at 12:13:31 UTC, Adam D Ruppe wrote:


 [...]

 Murilo might not need a big number lib at all.
 
 For astronomy, there's a good chance floating point will do 
 the job.


 
 That not going to work if you are comparing things that are 
 extremely big with something that is extremely small here.


 [...]

 I think you got that wrong, floating is precisely designed for 
 such comparisons. You can easily compare 1e+1000 with 1e-1000 
 without running into problems.

 Where you might run into problems is if you *add* (or subtract) 
 extremely small numbers from extremely big numbers. Or if you 
 divide by extremely small numbers. Or in general perform 
 operations that mix numbers of greatly unlike magnitudes.


 T


Yes, and Adam did take out a double indemnity with "might not" 
and "good chance". The long dormant physicist in me is curious to 
see an example calculation/formula from Murilo, and his hoped-for 
precision at the end.
Mar 29 2022
prev sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Tuesday, 29 March 2022 at 15:23:45 UTC, H. S. Teoh wrote:

 On Tue, Mar 29, 2022 at 01:58:46PM +0000, 12345swordy via 
 Digitalmars-d wrote:

 On Tuesday, 29 March 2022 at 12:13:31 UTC, Adam D Ruppe wrote:


 [...]

 Murilo might not need a big number lib at all.
 
 For astronomy, there's a good chance floating point will do 
 the job.


 
 That not going to work if you are comparing things that are 
 extremely big with something that is extremely small here.


 [...]

 I think you got that wrong, floating is precisely designed for 
 such comparisons. You can easily compare 1e+1000 with 1e-1000 
 without running into problems.

 Where you might run into problems is if you *add* (or subtract) 
 extremely small numbers from extremely big numbers. Or if you 
 divide by extremely small numbers. Or in general perform 
 operations that mix numbers of greatly unlike magnitudes.


 T


Where did you get the 1e+1000 number from? That is way bigger 
then the official max size of double.
https://docs.microsoft.com/en-us/dotnet/api/system.double.maxvalue?view=net-6.0

-Alex
Mar 29 2022
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Mar 29, 2022 at 05:25:39PM +0000, 12345swordy via Digitalmars-d wrote:

 On Tuesday, 29 March 2022 at 15:23:45 UTC, H. S. Teoh wrote:


[...]

 I think you got that wrong, floating is precisely designed for such
 comparisons. You can easily compare 1e+1000 with 1e-1000 without running
 into problems.




[...]

 Where did you get the 1e+1000 number from? That is way bigger then the
 official max size of double.


[...]

Oops, meant to write 300, not 1000. :-O  The 1000 is for the binary
representation, not for decimal.


T

-- 
There are three kinds of people in the world: those who can count, and those
who can't.
Mar 29 2022
prev sibling next sibling parent Mike Parker <aldacron gmail.com> writes:
On Friday, 25 March 2022 at 23:33:45 UTC, Murilo wrote:

 I have been waiting for years now, can't you guys just add 
 these 2 types to the language?


Walter has plans to deprecate cent/ucent in favor of a library 
implementation. See the “128 bit integers” section in the summary 
of our last meeting here:

https://forum.dlang.org/post/qrtjqubrbuqeiffunili forum.dlang.org
Mar 25 2022
prev sibling next sibling parent Era Scarecrow <rtcvb32 yahoo.com> writes:
On Friday, 25 March 2022 at 23:33:45 UTC, Murilo wrote:

 I have been waiting for years now, can't you guys just add 
 these 2 types to the language?


  I have a library i wrote a few years ago you can use. Compiled 
it recently and had no issues. It may need more testing. Should 
handle any multiple of 64bits, even odd ones. though doing 
128/256 and others should be just fine.

https://github.com/rtcvb32/Side-Projects/tree/master/arbitraryint

used as **import std.experimental/arbitraryint;**

Though i'm not sure if i need to update it for licenses, it has 
been a while afterall... For now avoid using it in commercial 
products.
Mar 25 2022
prev sibling next sibling parent reply Salih Dincer <salihdb hotmail.com> writes:
On Friday, 25 March 2022 at 23:33:45 UTC, Murilo wrote:

 I have been waiting for years now, can't you guys just add 
 these 2 types to the language?



The code is a bit old, but it works flawlessly and has useful 
aliases:

https://github.com/d-gamedev-team/gfm/blob/master/integers/gfm/integers/wideint.d
Mar 26 2022
next sibling parent Guillaume Piolat <first.last gmail.com> writes:
On Saturday, 26 March 2022 at 11:37:28 UTC, Salih Dincer wrote:

 On Friday, 25 March 2022 at 23:33:45 UTC, Murilo wrote:

 I have been waiting for years now, can't you guys just add 
 these 2 types to the language?



 The code is a bit old, but it works flawlessly and has useful 
 aliases:

 https://github.com/d-gamedev-team/gfm/blob/master/integers/gfm/integers/wideint.d


I think it just need to be in a dub package one can find.
Mar 26 2022
prev sibling parent Era Scarecrow <rtcvb32 yahoo.com> writes:
On Saturday, 26 March 2022 at 11:37:28 UTC, Salih Dincer wrote:

 The code is a bit old, but it works flawlessly and has useful 
 aliases:

 https://github.com/d-gamedev-team/gfm/blob/master/integers/gfm/integers/wideint.d


  Flawless maybe, but definitely slow when you get to division. It 
can only double the size of integers.

  If memory serves me right, it uses shift and subtraction for 
division, but it also uses 2 lower types so if you do say a 
256bit type, it creates and uses 2 128 bit types, which uses 2 64 
bit types to do the job.
Mar 26 2022
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/25/2022 4:33 PM, Murilo wrote:

 I have been waiting for years now, can't you guys just add these 2 types to
the 
 language?


I did some work implementing it as a native type. But after a while I realized 
that it was not appropriate to implement it that way, it should be a library 
type like `complex` is.

The library type hasn't been implemented (anyone is free to do this!), but the 
math part has been:

https://dlang.org/phobos/core_int128.html
Mar 26 2022
next sibling parent reply Era Scarecrow <rtcvb32 yahoo.com> writes:
On Saturday, 26 March 2022 at 19:30:13 UTC, Walter Bright wrote:

 On 3/25/2022 4:33 PM, Murilo wrote:

 I have been waiting for years now, can't you guys just add 
 these 2 types to the language?


 I did some work implementing it as a native type. But after a 
 while I realized that it was not appropriate to implement it 
 that way, it should be a library type like `complex` is.

 The library type hasn't been implemented (anyone is free to do 
 this!), but the math part has been:

 https://dlang.org/phobos/core_int128.html


  Multiplication and division are the only parts needing any real 
work, most of it is very simple. As mentioned i have my library 
written, though i suppose i'd have to fight a bit with github 
that i never quite got working before when doing bitmanip 
bitfields.

  Though, if int128 just forwards calls to my library that would 
be far easier to implement while keeping the assembly code... 
I'll see about tinkering with this.
Mar 26 2022
parent reply Salih Dincer <salihdb hotmail.com> writes:
On Sunday, 27 March 2022 at 03:10:41 UTC, Era Scarecrow wrote:

 [...] i'd have to fight a bit with github that i never quite 
 got working before when doing bitmanip bitfields.

  Though, if int128 just forwards calls to my library that would 
 be far easier to implement while keeping the assembly code... 
 I'll see about tinkering with this.


I hope you will be successful because we need to use it without 
writing import.  Really, is it that hard?  By simply 
implementing, the codes that we write can run slow! It can be 
accelerated by 2030. Even if the background BigInt library can 
work collaboratively.

In summary let's use that cent and ucent henceforth, please 
without import lines!

SDB 79
Mar 27 2022
parent reply Era Scarecrow <rtcvb32 yahoo.com> writes:
On Sunday, 27 March 2022 at 07:23:59 UTC, Salih Dincer wrote:

 I hope you will be successful because we need to use it without 
 writing import.  Really, is it that hard?  By simply 
 implementing, the codes that we write can run slow! It can be 
 accelerated by 2030. Even if the background BigInt library can 
 work collaboratively.


One could just use BigInt under the hood and then have it do 
checks at certain points and modify it to fit in the appropriate 
128bit limits. Though i don't see that being useful, plus you 
would want to run it without any allocation for embedded and low 
memory devices.


 In summary let's use that cent and ucent henceforth, please 
 without import lines!


Not needing an import would be nice, but it is more syntactical 
sugar, much like how you don't need to import the basic Object 
type, just being done under the hood doesn't mean that much. 
Somewhere it would just be that cent outside of the core would be 
```alias cent=Cent;``` otherwise cent/ucent would be reserved 
words.

  Though as long as you're at it, if you want to specify 
256/512/1024 types now would be the time to decide the names and 
put them in all at once.



  I glanced at the work Walter did. Looks like a simple version of 
wideint. I thought it would just be the function prototypes. 
Instead it looks like he minimally implemented it, but it is 
basically just in the wrong spot, or not set to being called at 
all (*not too familiar with the internals i'm not sure*). If 
these are ready to be used, I'd just swap out the 
division/multiplication work for faster variants and call it good.

  Though there's a number of features there that i hadn't 
implemented, primarily the bit rotation types that aren't 
represented in C/D, and thus didn't see the need to at the time.
Mar 27 2022
parent user1234 <user1234 12.de> writes:
On Sunday, 27 March 2022 at 16:41:33 UTC, Era Scarecrow wrote:


  I glanced at the work Walter did. Looks like a simple version 
 of wideint. I thought it would just be the function prototypes. 
 Instead it looks like he minimally implemented it, but it is 
 basically just in the wrong spot, or not set to being called at 
 all (*not too familiar with the internals i'm not sure*).


To be called, the remaining work is that a library type must be 
implemented with operator overloads. Those operators overloads 
will call the core int128 module routines. Also operators 
overloads being templates, we can expect to have a size-efficient 
cg ("pay as you go").

druntime is the right place. For example LDC can patch the 
default implementation and use the LLVM-specific i128 
instructions. The library type will end up using the right thing.

At this point it looks like it still *would* be possible to hook 
cent/ucent operations to the int128 core module even if it's not 
the way that's been chosen as cent/ucent are now deprecated.
Mar 27 2022
prev sibling next sibling parent Salih Dincer <salihdb hotmail.com> writes:
On Saturday, 26 March 2022 at 19:30:13 UTC, Walter Bright wrote:

 On 3/25/2022 4:33 PM, Murilo wrote:

 I have been waiting for years now, can't you guys just add 
 these 2 types to the language?


 I did some work implementing it as a native type. But after a 
 while I realized that it was not appropriate to implement it 
 that way, it should be a library type like `complex` is.


I guess I must have missed this "complexity" detail, as I didn't 
contribute to development of D. I think it should stay at the 
library level. Obviously, the library is sufficient for Murilo...

SDB 79
Mar 27 2022
prev sibling parent reply Guillaume Piolat <first.last google.com> writes:
On Saturday, 26 March 2022 at 19:30:13 UTC, Walter Bright wrote:

 https://dlang.org/phobos/core_int128.html


I tried to find faults in its divide and modulo so that I could 
rant about wideint.d being rewritten, but actually core.int128 
seems to be better and correct (possibly more correct with 
negative modulo even). :)

So now it's all about adding the operator overloads, and done 
with that particular complaint!
Mar 28 2022
next sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Monday, 28 March 2022 at 18:37:27 UTC, Guillaume Piolat wrote:

 On Saturday, 26 March 2022 at 19:30:13 UTC, Walter Bright wrote:

 https://dlang.org/phobos/core_int128.html


 I tried to find faults in its divide and modulo so that I could 
 rant about wideint.d being rewritten, but actually core.int128 
 seems to be better and correct (possibly more correct with 
 negative modulo even). :)

 So now it's all about adding the operator overloads, and done 
 with that particular complaint!


With LDC 1.27.1 :

```d
Cent foobar(Cent a, Cent b) {
     return mul(a, b);
}
```

Codegen:
```asm
nothrow  nogc  safe example.Cent example.foobar(example.Cent, 
example.Cent):
         push    r15
         push    r14
         push    rbx
         mov     r9d, edi
         mov     r8, rdi
         shr     r8, 32
         mov     r11d, esi
         mov     r10, rsi
         shr     r10, 32
         mov     ebx, edx
         mov     rax, rbx
         imul    r11, rbx
         imul    rbx, r9
         imul    rax, r8
         mov     r14d, ebx
         shr     rbx, 32
         add     rbx, rax
         mov     eax, ebx
         shr     rbx, 32
         add     rbx, r11
         imul    r10d, edx
         shr     rdx, 32
         mov     r11, rdx
         imul    r11, r9
         add     rax, r11
         mov     r11, rdx
         imul    r11, r8
         mov     r15d, ebx
         add     r15, r11
         mov     r11, rax
         shr     r11, 32
         add     r11, r15
         imul    edx, esi
         add     edx, r10d
         mov     r10d, ecx
         imul    r10, r9
         mov     esi, r11d
         add     rsi, r10
         imul    r8d, ecx
         add     r8d, edx
         shr     rcx, 32
         imul    ecx, edi
         add     ecx, r8d
         shl     rax, 32
         or      rax, r14
         shl     rcx, 32
         add     rcx, rbx
         movabs  rdx, -4294967296
         and     rcx, rdx
         add     rcx, r11
         and     rcx, rdx
         add     rsi, rcx
         mov     rdx, rsi
         pop     rbx
         pop     r14
         pop     r15
         ret
```

Now let's see what we can get with clang and __int128_t, same 
backend so the comparison is fair:

```cpp
__uint128_t foobar(__uint128_t a, __uint128_t b) {
     return a * b;
}
```

codegen:
```asm
foobar(unsigned __int128, unsigned __int128):                     

         mov     r8, rdx
         mov     rax, rdx
         mul     rdi
         imul    rsi, r8
         add     rdx, rsi
         imul    rcx, rdi
         add     rdx, rcx
         ret
```

Why do I even have to argue that case?
Mar 28 2022
next sibling parent reply Era Scarecrow <rtcvb32 yahoo.com> writes:
On Monday, 28 March 2022 at 19:35:10 UTC, deadalnix wrote:

 Why do I even have to argue that case?


  Because different architectures and compilers do different 
things. And some people value correctness over speed, especially 
if later we do get 128bit registers we want it to work exactly as 
expected when it gets recompiled.

  Though i'm sure you know this and are just doing raw comparison 
of size.

  Writing these functions using purely C you can manage to get the 
job done but it's a lot more work and takes a lot more steps. I 
ended up writing some of my hardware specific functions 3 times, 
32bit, 64bit and generic. 32/64bit worked quite well with asm to 
speed things up for any size you'd want. Generic however didn't 
like it as much and actually is **SLOWER** than 32bit, but should 
work on anything and even works in CTFE (*to make it as close to 
a native type as i could*)

  What i wrote should be close to the level of the cpp example, 
just won't be inlined; Though i suppose i could write an inline 
one **just** for 128bit which would be a lot easier to inline for 
one level up...
Mar 28 2022
parent reply deadalnix <deadalnix gmail.com> writes:
On Tuesday, 29 March 2022 at 06:28:17 UTC, Era Scarecrow wrote:

 On Monday, 28 March 2022 at 19:35:10 UTC, deadalnix wrote:

 Why do I even have to argue that case?


  Because different architectures and compilers do different 
 things. And some people value correctness over speed, 
 especially if later we do get 128bit registers we want it to 
 work exactly as expected when it gets recompiled.


No, I picked the exact same toolchain on purpose so that the 
approach themselves can be compared.

There is no correctness vs speed here, both code are correct. One 
is going to be significantly faster, but, in addition, one is 
going to optimize better with it surroundings, so what you'll see 
in practice is an even wider gap that what is presented above.

This approach will not work. I know because I specifically worked 
on making LLVM optimize this type of code and know how much 
harder it is to get good code in the presence of 128 bits 
integers vs in their absence.

The CPU has a lot of instructions to help handle large integers. 
When you let the backend do its magic, it can leverage them. When 
you instead give it good old small integers code and it has to 
infer the meaning from it and reconstruct the large integers ops 
you meant to be doing and optmize that, you introduce so many 
failure point that it's practically impossible to get a 
competitive result.

Once again, both of the exemple above you *THE EXACT SAME* 
toolchain, the only different is the approach to 128 bits 
integers in the frontend.
Mar 29 2022
next sibling parent reply max haughton <maxhaton gmail.com> writes:
On Tuesday, 29 March 2022 at 12:06:54 UTC, deadalnix wrote:

 On Tuesday, 29 March 2022 at 06:28:17 UTC, Era Scarecrow wrote:

[...]


 No, I picked the exact same toolchain on purpose so that the 
 approach themselves can be compared.

 There is no correctness vs speed here, both code are correct. 
 One is going to be significantly faster, but, in addition, one 
 is going to optimize better with it surroundings, so what 
 you'll see in practice is an even wider gap that what is 
 presented above.

 This approach will not work. I know because I specifically 
 worked on making LLVM optimize this type of code and know how 
 much harder it is to get good code in the presence of 128 bits 
 integers vs in their absence.

 The CPU has a lot of instructions to help handle large 
 integers. When you let the backend do its magic, it can 
 leverage them. When you instead give it good old small integers 
 code and it has to infer the meaning from it and reconstruct 
 the large integers ops you meant to be doing and optmize that, 
 you introduce so many failure point that it's practically 
 impossible to get a competitive result.

 Once again, both of the exemple above you *THE EXACT SAME* 
 toolchain, the only different is the approach to 128 bits 
 integers in the frontend.


I agree. Having dmd as a fast backend is OK but if something as 
basically trivial as this cannot be implemented the we are in 
trouble.

That being said it may be possible to lower the cent type to the 
druntime type as a hack, then LDC and GDC can do what they need 
to do.
Mar 29 2022
parent Guillaume Piolat <first.last gmail.com> writes:
On Tuesday, 29 March 2022 at 12:20:21 UTC, max haughton wrote:

 That being said it may be possible to lower the cent type to 
 the druntime type as a hack, then LDC and GDC can do what they 
 need to do.


In intel-intrinsics, unsupported vector types are emulated:
   - all vectors in DMD 32-bit
   - all vectors in DMD 64-bit with an option that disable D_SIMD
   - AVX vectors in GDC without AVX

so it's just a matter of adding a version there and some work, to 
have backend support AND work everywhere.
Mar 29 2022
prev sibling parent reply Era Scarecrow <rtcvb32 yahoo.com> writes:
On Tuesday, 29 March 2022 at 12:06:54 UTC, deadalnix wrote:

 No, I picked the exact same toolchain on purpose so that the 
 approach themselves can be compared.
 both of the example above you *THE EXACT SAME* toolchain, the 
 only different is the approach to 128 bits integers in the 
 frontend.


  To me it looked like you did a C++ vs D somewhere in the way. 
But instead you're just doing the backend calls.

  Also speaks of a bunch of my own inexperience in the deeper 
matters, and why i usually abstain from a number of these 
conversations I'm not well versed in.


 The CPU has a lot of instructions to help handle large 
 integers. When you let the backend do its magic, it can 
 leverage them. When you instead give it good old small integers 
 code and it has to infer the meaning from it and reconstruct  
 the large integers ops you meant to be doing and optimize that, 
 you introduce so many failure point that it's practically 
 impossible to get a competitive result.


  Reminded of reading of specific ways you had to write bswap in 
C/C++ for GCC to recognize it and reduce it to a single 
instruction without getting into ASM, while still working with 
architectures that didn't have that specific instruction.


 There is no correctness vs speed here, both code are correct. 
 One is going to be significantly faster, but, in addition, one 
 is going to optimize better with it surroundings, so what 
 you'll see in practice is an even wider gap that what is 
 presented above.


  Still that example does suggest I'd get a bit of a boost by 
manually writing the 128bit multiply manually which would cut out 
overhead and a loop that's unneeded. Probably get similar results 
with a divide (*with long or smaller divisor*). Course those are 
rather case specific.

  I wouldn't look forward to re-writing the same code for all the 
different compilers back ends though.
Mar 29 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/29/2022 9:36 AM, Era Scarecrow wrote:

   I wouldn't look forward to re-writing the same code for all the different 
 compilers back ends though.


That's the attractiveness of a builtin function. It'll at least work for other 
systems.
Mar 30 2022
parent reply Quirin Schroll <qs.il.paperinik gmail.com> writes:
On Thursday, 31 March 2022 at 06:33:26 UTC, Walter Bright wrote:

 On 3/29/2022 9:36 AM, Era Scarecrow wrote:

   I wouldn't look forward to re-writing the same code for all 
 the different compilers back ends though.


 That's the attractiveness of a builtin function. It'll at least 
 work for other systems.


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.

I’m not entirely sure if I’m being serious here, but on the other 
hand, I know of no other language that reserved a type keyword 
and doesn’t use it although it easily could.
Mar 31 2022
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
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.
Mar 31 2022
parent reply Tejas <notrealemail gmail.com> writes:
On Friday, 1 April 2022 at 03:37:48 UTC, rikki cattermole wrote:

 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.


So will this look something like
```d
alias i128 = __traits(signed, 128);
alias u512 = __traits(unsigned, 512);
```
And so on?
Mar 31 2022
next sibling parent Era Scarecrow <rtcvb32 yahoo.com> writes:
On Friday, 1 April 2022 at 04:48:02 UTC, Tejas wrote:

 On Friday, 1 April 2022 at 03:37:48 UTC, rikki cattermole wrote:

 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.


 So will this look something like
 ```d
 alias i128 = __traits(signed, 128);
 alias u512 = __traits(unsigned, 512);
 ```
 And so on?


Maybe. Some use int32 as the identifier rather than int.

Though my library i specify the bit size and it uses N number of 
longs to fulfill that so it could fit any type until there's 
hardware support and you just replace the alias.

I don't know. As long as various sizes are supported easily i 
don't object to whatever people decide on.
Mar 31 2022
prev sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 01/04/2022 5:48 PM, Tejas wrote:

 So will this look something like
 ```d
 alias i128 = __traits(signed, 128);
 alias u512 = __traits(unsigned, 512);
 ```
 And so on?


The name could be whatever you want, but yeah.
Mar 31 2022
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 4/1/22 1:47 AM, rikki cattermole wrote:

 
 On 01/04/2022 5:48 PM, Tejas wrote:

 So will this look something like
 ```d
 alias i128 = __traits(signed, 128);
 alias u512 = __traits(unsigned, 512);
 ```
 And so on?


 
 The name could be whatever you want, but yeah.


As long as the compiler errors display the alias and not the traits.

-Steve
Apr 01 2022
parent rikki cattermole <rikki cattermole.co.nz> writes:
Indeed, this is one time when typedef's would be better suited to the task.
Apr 01 2022
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/28/2022 12:35 PM, deadalnix wrote:

 Now let's see what we can get with clang and __int128_t, same backend so the 
 comparison is fair:
 
 ```cpp
 __uint128_t foobar(__uint128_t a, __uint128_t b) {
      return a * b;
 }
 ```
 
 codegen:
 ```asm

 __int128, unsigned __int128)
          mov     r8, rdx
          mov     rax, rdx
          mul     rdi
          imul    rsi, r8
          add     rdx, rsi
          imul    rcx, rdi
          add     rdx, rcx
          ret
 ```
 
 Why do I even have to argue that case?


You see a similar thing when 32 bit compilation does 64 bit arithmetic:

ulong foobar(ulong x, ulong y)
{
     return x * y;
}

dmd -c test.d -vasm -m32 -O
_D4test6foobarFmmZm:
0000:   53                       push      EBX
0001:   8B 54 24 14              mov       EDX,014h[ESP]
0005:   8B 44 24 10              mov       EAX,010h[ESP]
0009:   8B 4C 24 0C              mov       ECX,0Ch[ESP]
000d:   8B 5C 24 08              mov       EBX,8[ESP]
0011:   0F AF C8                 imul      ECX,EAX
0014:   0F AF D3                 imul      EDX,EBX
0017:   03 CA                    add       ECX,EDX
0019:   F7 E3                    mul       EBX
001b:   03 D1                    add       EDX,ECX
001d:   5B                       pop       EBX
001e:   C2 10 00                 ret       010h

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.
Mar 30 2022
parent reply deadalnix <deadalnix gmail.com> writes:
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.
Mar 31 2022
next sibling parent reply kinke <noone nowhere.com> writes:
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.
Mar 31 2022
next sibling parent reply max haughton <maxhaton gmail.com> writes:
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.
Mar 31 2022
next sibling parent reply kinke <noone nowhere.com> writes:
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.
Mar 31 2022
parent max haughton <maxhaton gmail.com> writes:
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.
Mar 31 2022
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Mar 31 2022
next sibling parent 12345swordy <alexanderheistermann gmail.com> writes:
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.
Mar 31 2022
prev sibling parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
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.


For the past 2.5 years, I've worked on applications that use 
256-bit integers for most of the computation (because the inputs 
are 256-bit numbers typically used to represent fixed point 
decimals with 18 digits) for computation and it would have been 
nice to to have uint256/int256 built-in types, instead of having 
to use a library BigInt type.
Mar 31 2022
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/31/2022 10:33 PM, Petar Kirov [ZombineDev] wrote:

 For the past 2.5 years, I've worked on applications that use 256-bit integers 
 for most of the computation (because the inputs are 256-bit numbers typically 
 used to represent fixed point decimals with 18 digits) for computation and it 
 would have been nice to to have uint256/int256 built-in types, instead of
having 
 to use a library BigInt type.


A library 128 bit type would be pretty easy to do, now that the computation 
functions are worked out. 256 bits could leverage that.

But frankly, with all the jawboning around it could have already been 
implemented. Just take:

   https://github.com/dlang/phobos/blob/master/std/complex.d

and de-template it, and delete most of it, and you've got struct Int128 and 
struct Uint128. The hard part:

   https://github.com/dlang/druntime/blob/master/src/core/int128.d

is already done.

Whoever does it first gets the glory :-)
Apr 01 2022
parent reply mee6 <mee6 lookat.me> writes:
On Friday, 1 April 2022 at 07:22:21 UTC, Walter Bright wrote:

 On 3/31/2022 10:33 PM, Petar Kirov [ZombineDev] wrote:

 [...]


 A library 128 bit type would be pretty easy to do, now that the 
 computation functions are worked out. 256 bits could leverage 
 that.

 But frankly, with all the jawboning around it could have 
 already been implemented. Just take:

   https://github.com/dlang/phobos/blob/master/std/complex.d

 and de-template it, and delete most of it, and you've got 
 struct Int128 and struct Uint128. The hard part:

   
 https://github.com/dlang/druntime/blob/master/src/core/int128.d

 is already done.

 Whoever does it first gets the glory :-)


I'd do it for money lol
Apr 01 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/1/2022 7:23 AM, mee6 wrote:

 Whoever does it first gets the glory :-)


 
 I'd do it for money lol


What the hell, I'm tired of the jawboning and did it for the greater glory:

https://github.com/dlang/phobos/pull/8426
Apr 02 2022
next sibling parent reply Salih Dincer <salihdb hotmail.com> writes:
On Saturday, 2 April 2022 at 22:41:52 UTC, Walter Bright wrote:

 On 4/1/2022 7:23 AM, mee6 wrote:

 Whoever does it first gets the glory :-)


 
 I'd do it for money lol


 What the hell, I'm tired of the jawboning and did it for the 
 greater glory:

 https://github.com/dlang/phobos/pull/8426


Thank you on behalf of myself. I wish I could a little support 
but I haven't gotten very far in D Language yet.

SDB 79
Apr 02 2022
parent Salih Dincer <salihdb hotmail.com> writes:
On Saturday, 2 April 2022 at 23:12:27 UTC, Salih Dincer wrote:

 I wish I could a little support but I haven't gotten very far 
 in D Language yet.


I don't know how to add it to Github. A small contribution, they 
work:

**Lines,70-77**
```d
// ++Int128
     Int128 opUnary(string op)() const
         if (op == "++")
     {
         return Int128(inc(this.data));
     }
// --Int128
     Int128 opUnary(string op)() const
         if (op == "--")
     {
         return Int128(dec(this.data));
     }
//...
unittest {
     Int128 idTest;

     idTest += ulong.max;// hi = 1, lo = 0->
     assert(++idTest == Int128(1, 0));

     idTest = ++idTest;// hi = 0, lo = ulong.max->
     assert(--idTest == Int128(0, -1));
}
```
SDB 79
Apr 02 2022
prev sibling parent Murilo <murilomiranda92 hotmail.com> writes:
On Saturday, 2 April 2022 at 22:41:52 UTC, Walter Bright wrote:

 On 4/1/2022 7:23 AM, mee6 wrote:

 Whoever does it first gets the glory :-)


 
 I'd do it for money lol


 What the hell, I'm tired of the jawboning and did it for the 
 greater glory:

 https://github.com/dlang/phobos/pull/8426


Thank you for your work, I'm very happy and thankful.

I will try to add it to my decimal calculator module now.
Feb 21 2023
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Friday, 1 April 2022 at 05:33:06 UTC, Petar Kirov [ZombineDev] 
wrote:

 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.


 For the past 2.5 years, I've worked on applications that use 
 256-bit integers for most of the computation (because the 
 inputs are 256-bit numbers typically used to represent fixed 
 point decimals with 18 digits) for computation and it would 
 have been nice to to have uint256/int256 built-in types, 
 instead of having to use a library BigInt type.


I have done that.

While it is not possible to get good codegen with the current 
provided types, it is possible with a 128bit type. You can then 
do your operation using a 128 bits accumulator and compiler are 
smart enough to figure out what to do most of the time.

This is why a 128 bit type is absolutely key, it unlocks the 
ability to write larger integer types in a way that will allow 
the compiler to generate good code for it.
Apr 01 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 1 April 2022 at 12:06:01 UTC, deadalnix wrote:

 This is why a 128 bit type is absolutely key, it unlocks the 
 ability to write larger integer types in a way that will allow 
 the compiler to generate good code for it.


Does LLVM support that width good code gen? Intel/AMD have some 
instructions intended for higher precision math 
([ADX](https://en.wikipedia.org/wiki/Intel_ADX), 
[MULX](https://en.wikipedia.org/wiki/X86_Bit_manipulation_ins
ruction_set#BMI2)). They also have some instructions meant to be used for
crypto, e.g. [CLMUL](https://en.wikipedia.org/wiki/CLMUL_instruction_set).
Apr 11 2022
parent reply user1234 <user1234 12.de> writes:
On Monday, 11 April 2022 at 07:24:41 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 1 April 2022 at 12:06:01 UTC, deadalnix wrote:

 This is why a 128 bit type is absolutely key, it unlocks the 
 ability to write larger integer types in a way that will allow 
 the compiler to generate good code for it.


 Does LLVM support that width good code gen? Intel/AMD have some 
 instructions intended for higher precision math 
 ([ADX](https://en.wikipedia.org/wiki/Intel_ADX), 
 [MULX](https://en.wikipedia.org/wiki/X86_Bit_manipulation_ins
ruction_set#BMI2)). They also have some instructions meant to be used for
crypto, e.g. [CLMUL](https://en.wikipedia.org/wiki/CLMUL_instruction_set).


LLVM 128 type (named `i128`) on x86_64 produces standard 
instructions, e.g more or less the D library implementation with 
better code gen, [example].

[example]: https://godbolt.org/z/vfYhc3bTn
Apr 11 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 11 April 2022 at 07:44:04 UTC, user1234 wrote:

 On Monday, 11 April 2022 at 07:24:41 UTC, Ola Fosheim Grøstad 
 wrote:

 Intel/AMD have some instructions intended for higher precision 
 math ([ADX](https://en.wikipedia.org/wiki/Intel_ADX), 
 [MULX](https://en.wikipedia.org/wiki/X86_Bit_manipulation_ins
ruction_set#BMI2)). They also have some instructions meant to be used for
crypto, e.g. [CLMUL](https://en.wikipedia.org/wiki/CLMUL_instruction_set).


 LLVM 128 type (named `i128`) on x86_64 produces standard 
 instructions, e.g more or less the D library implementation 
 with better code gen, [example].

 [example]: https://godbolt.org/z/vfYhc3bTn


Thanks, it appears to use "MULX" if you specify the compiler 
option `-mattr=bmi2` or a `-mcpu=haswell`.
Apr 11 2022
parent user1234 <user1234 12.de> writes:
On Monday, 11 April 2022 at 08:15:09 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 11 April 2022 at 07:44:04 UTC, user1234 wrote:

 On Monday, 11 April 2022 at 07:24:41 UTC, Ola Fosheim Grøstad 
 wrote:

 Intel/AMD have some instructions intended for higher 
 precision math 
 ([ADX](https://en.wikipedia.org/wiki/Intel_ADX), 
 [MULX](https://en.wikipedia.org/wiki/X86_Bit_manipulation_ins
ruction_set#BMI2)). They also have some instructions meant to be used for
crypto, e.g. [CLMUL](https://en.wikipedia.org/wiki/CLMUL_instruction_set).


 LLVM 128 type (named `i128`) on x86_64 produces standard 
 instructions, e.g more or less the D library implementation 
 with better code gen, [example].

 [example]: https://godbolt.org/z/vfYhc3bTn


 Thanks, it appears to use "MULX" if you specify the compiler 
 option `-mattr=bmi2` or a `-mcpu=haswell`.


Actually, as said in the beginning of the thread I expect that 
eventually LDC developers will patch their fork of the D runtime, 
assuming `i128` has the same ABI as the structure used in D... 
although the D implementation must still be there in some way for 
CTFE.
Apr 11 2022
prev sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
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.


 The existing generic software implementation is still useful 
 for CTFE.


Yep, they were all written to be CTFE-friendly.
Apr 02 2022
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Mar 31 2022
prev sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
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;
Apr 02 2022
prev sibling next sibling parent reply Johan <j j.nl> writes:
On Monday, 28 March 2022 at 19:35:10 UTC, deadalnix wrote:

 Why do I even have to argue that case?


Indeed. Bump. People please re-read deadalnix messages.

-Johan
Mar 31 2022
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 31.03.22 18:32, Johan wrote:

 On Monday, 28 March 2022 at 19:35:10 UTC, deadalnix wrote:

 Why do I even have to argue that case?


 
 Indeed. Bump. People please re-read deadalnix messages.
 
 -Johan
 


Well, I was with deadalnix on this even before reading the messages 
once. Add cent/ucent as built-in integral types. I was always under the 
impression that that the plan was to do it eventually.

I guess there are some inconvenient features to add to the frontend 
code, e.g. VRP, where a "library" solution would have an obvious excuse 
to just not support them.

If adding cent/ucent to the DMD backend is not an option, it can just 
forward to the druntime type, but other backends should be free to 
leverage their existing implementation. All of this is completely 
independent of whether or not cent/ucent are built-ins in the frontend 
anyway.

BTW: It's perfectly fine to just add cent/ucent built-in implementation 
to the vision document and maybe provide a small spec of it, then 
someone who needs it can implement it.
Mar 31 2022
prev sibling parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On Monday, 28 March 2022 at 19:35:10 UTC, deadalnix wrote:

 On Monday, 28 March 2022 at 18:37:27 UTC, Guillaume Piolat 
 wrote:

 On Saturday, 26 March 2022 at 19:30:13 UTC, Walter Bright 
 wrote:

 https://dlang.org/phobos/core_int128.html


 I tried to find faults in its divide and modulo so that I 
 could rant about wideint.d being rewritten, but actually 
 core.int128 seems to be better and correct (possibly more 
 correct with negative modulo even). :)

 So now it's all about adding the operator overloads, and done 
 with that particular complaint!


 With LDC 1.27.1 :

 ```d
 Cent foobar(Cent a, Cent b) {
     return mul(a, b);
 }
 ```

 Codegen:


[--snip--]

Being free functions, LDC is free to recognize them as intrinsics 
and do the desirable thing here.
Apr 02 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Another advantage to core.int128 is any soft implementation of a 128 bit
integer 
does not need to concern itself with the correctness of the arithmetic - just 
the user side of the integer type.

I also like core.int128 does not import anything else, making it a true leaf
module.

Edit: Oh darn, it imports core.bitop!
Apr 02 2022
parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On Saturday, 2 April 2022 at 19:06:01 UTC, Walter Bright wrote:

 Another advantage to core.int128 is any soft implementation of 
 a 128 bit integer does not need to concern itself with the 
 correctness of the arithmetic - just the user side of the 
 integer type.

 I also like core.int128 does not import anything else, making 
 it a true leaf module.

 Edit: Oh darn, it imports core.bitop!


It's only bsr, the compiler inlines that into one instruction. ;-)
Apr 02 2022
parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/2/2022 2:40 PM, Iain Buclaw wrote:

 On Saturday, 2 April 2022 at 19:06:01 UTC, Walter Bright wrote:

 Another advantage to core.int128 is any soft implementation of a 128 bit 
 integer does not need to concern itself with the correctness of the arithmetic 
 - just the user side of the integer type.

 I also like core.int128 does not import anything else, making it a true leaf 
 module.

 Edit: Oh darn, it imports core.bitop!


 
 It's only bsr, the compiler inlines that into one instruction. ;-)


I know. I was dreading doing the work you did for divide, glad you picked up
the 
flag! I had done the equivalent for DMC's long divide long ago.
Apr 02 2022
prev sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On Monday, 28 March 2022 at 18:37:27 UTC, Guillaume Piolat wrote:

 On Saturday, 26 March 2022 at 19:30:13 UTC, Walter Bright wrote:

 https://dlang.org/phobos/core_int128.html


 I tried to find faults in its divide and modulo so that I could 
 rant about wideint.d being rewritten, but actually core.int128 
 seems to be better and correct (possibly more correct with 
 negative modulo even). :)


Thanks, I took a page from hacker's delight when re-implementing 
the divmod() function, and did quite a bit of back and forth 
comparing results to wolfram. :-)
Apr 02 2022
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/25/2022 4:33 PM, Murilo wrote:

 I have been waiting for years now, can't you guys just add these 2 types to
the 
 language?


Well, I tried.

https://github.com/dlang/phobos/pull/8426
Apr 09 2022