Implement cent/ucent by rikkimax · Pull Request #23575 · dlang/dmd

rikkimax · 2026-08-12T02:54:15Z

For this we can thank DeepSeek v4 flash.

github-actions · 2026-08-12T03:02:57Z

DMD perf check

Metric	Base	PR	delta
compile hello.d (instr)	215.6 M	218.0 M	+1.14%
compile hello.d -O (instr)	234.1 M	236.6 M	+1.07%
compile Phobos (instr)	5,110.5 M	5,162.3 M	+1.01%
compile Phobos codegen (instr)	1,472.2 M	1,483.7 M	+0.78%
compile vibe.d (instr)	15,079.5 M	15,190.3 M	+0.73%
dmd binary size (stripped)	6.92 MB	7.01 MB	+1.30%
hello binary size	0.72 MB	0.72 MB	0.00%
peak RSS (compile hello.d)	43 MB	44 MB	+0.33%
peak RSS (compile Phobos)	617 MB	618 MB	+0.19%
peak RSS (compile vibe.d)	1916 MB	1918 MB	+0.10%

rikkimax · 2026-08-12T22:11:13Z

Mir, Mir-random, Phobos have got code that has been silently "supporting" (u)cent that is now erroring.

rikkimax · 2026-08-12T23:28:23Z

This is ready for a first pass over it @WalterBright, we can talk more at meeting about it.

ibuclaw · 2026-08-14T04:34:30Z

@@ -0,0 +1,173 @@
+# Plan: Implement `cent` and `ucent` (128-bit integers) in dmd


Why is this checked in?

Intentionally, learning things to give @LightBender data points for PhobosV3.

ibuclaw · 2026-08-14T04:44:22Z

+
+#pragma once
+
+#include <cstdint>


Include dsystem.h, not system headers in frontend code.

ibuclaw · 2026-08-14T04:49:22Z

+#include <cstdint>
+
+// Mirrors dmd.common.int128.Cent
+struct alignas(16) Cent


FYI this is not common code, so it's location is only a bit odd for that reason alone.

Other backends implement they own versions/library of double-int (and wide-int for N-sized integers), so maybe better to move to root library, along with overloads of all operators.

See longdouble as an example.

Though not really a problem. As downstreams can just move this file (and int128.d) to the bin and implement their own version that wraps their own backend type irrespective of where it is placed.

I did not add dmd.common.int128.

Also, common is just root but with some -betterC stuff, like attributes that were added. It's something that Andrei worked on years ago but didn't get very far with.

ibuclaw · 2026-08-14T04:54:38Z

    static IntegerExp literal();
 };

+class BigIntegerExp final : public Expression


No to introducing a new integer expression. Instead adapt the existing IntegerExp. 99% of the time it'll still use the fast path and do arithmetic on value.lo directly only (ensuring that hi is always 0)

You can still keep around the helpers like isCentType below to keep the double and single int paths separate. At the same time you'll save on a lot of duplication.

I have some concerns with that, which is why I did not do it that way.

Memory usage, from other experiments that @rainers has been doing the increase would be noticeable

In practice its operating on sinteger_t's; and integer_t, I suspect that this would have a lot more effect than you may realize. So there will be duplication regardless.

It'll scale to 256bit without hurting the smaller sizes (however they are not needed atm).

There'll be no growth in memory. It'll just be extended as needed, we already do this for general arrays.

union { dinteger_t _value; Cent* _widevalue; }

And we can get away with gating on the Type for now when reading the value as it's only cent to support.

To future proof for _BitInt or if D opts to have it's own N-sized integers, we'll have to give up the existing implementation and layout anyway (can store length in a ushort). The pervasiveness of assuming dinteger_t == 64 bits everywhere needs to be ejected from the compiler. Attempts to mitigate by not unifying all internal integer representations will just make things worse in the long run.

I've checked Expression, and there's even enough padding room to put in the length of a variable-sized integer here.

dmd/compiler/src/dmd/expression.d

Line 129 in 9703ff2

static struct BitFields

Obviously, just store a ushort with a generic name and then derived expressions can use it for whatever they like. Possibly even to move their bitfields into Expression itself to reduce even more memory.

ibuclaw · 2026-08-14T04:56:49Z

 import core.stdc.stdio;
 import dmd.arraytypes;
 import dmd.astenums;
+import dmd.common.int128 : Cent, add, sub, mul, div, udiv, divmod, udivmod, and, or, xor, com, neg, shl, shr, sar, lt, le, ult, ule, tst, MinusOne;


Suggested change

import dmd.common.int128 : Cent, add, sub, mul, div, udiv, divmod, udivmod, and, or, xor, com, neg, shl, shr, sar, lt, le, ult, ule, tst, MinusOne;

import dmd.common.int128;

Selectively importing the entire library is too jarring.

Either import the entire module at top-level, or selectively import as-needed at function-level.

thewilsonator · 2026-08-14T15:13:58Z

(merge conflicts)

Herringway · 2026-08-14T17:18:22Z

While I can't comment on the code itself, I do see a number of holes in the tests.

No tests for exponentiation
No tests for addition/subtraction with >64-bit values
I see fun(cent, non-cent) tests but no fun(non-cent, cent) tests
Very few tests for cent arrays
- No dynamic arrays
- No associative arrays
- No tests for any arrays as function parameters
- No tests for vector ops
No tests for cents as in parameters (these should get the passed-by-reference treatment normally, if I'm not mistaken?)
Value range propagation (ushort foo(ucent bar) => bar >> 96;)
More traits (__traits(isArithmetic), etc)
extern(C) interactions

rikkimax added the AI Generated Code that is generated by an LLM AI. label Aug 12, 2026

rikkimax force-pushed the int128 branch 5 times, most recently from e11d659 to 08340ba Compare August 12, 2026 21:52

rikkimax force-pushed the int128 branch 5 times, most recently from d596b2c to feaf0a2 Compare August 12, 2026 23:20

rikkimax requested a review from WalterBright August 12, 2026 23:28

ibuclaw requested changes Aug 14, 2026

View reviewed changes

Implement cent/ucent

7c64827

rikkimax force-pushed the int128 branch from feaf0a2 to 7c64827 Compare August 14, 2026 14:24

		@@ -0,0 +1,173 @@
		# Plan: Implement `cent` and `ucent` (128-bit integers) in dmd

	import dmd.common.int128 : Cent, add, sub, mul, div, udiv, divmod, udivmod, and, or, xor, com, neg, shl, shr, sar, lt, le, ult, ule, tst, MinusOne;
	import dmd.common.int128;


		#pragma once

		#include <cstdint>

Uh oh!

Uh oh!

Conversation

rikkimax commented Aug 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented Aug 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

DMD perf check

Uh oh!

rikkimax commented Aug 12, 2026

Uh oh!

rikkimax commented Aug 12, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ibuclaw Aug 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

thewilsonator commented Aug 14, 2026

Uh oh!

Herringway commented Aug 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

rikkimax commented Aug 12, 2026 •

edited

Loading

github-actions Bot commented Aug 12, 2026 •

edited

Loading

ibuclaw Aug 14, 2026 •

edited

Loading

Herringway commented Aug 14, 2026 •

edited

Loading