From 4e76fad655d1537878ace936a0cf12b264c2505e Mon Sep 17 00:00:00 2001 From: Simon Brooke Date: Fri, 14 Mar 2025 10:24:38 +0000 Subject: [PATCH] Revert to 60-bit bignum chunks; better `make test` rigging Still failing the three-chunk bignum unit tests --- Makefile | 2 +- src/arith/peano.h | 4 ++-- state-of-play.md | 18 ++++++++++++++++++ 3 files changed, 21 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index 67bb015..b4f9d3c 100644 --- a/Makefile +++ b/Makefile @@ -36,7 +36,7 @@ else indent $(INDENT_FLAGS) $(SRCS) $(HDRS) endif -test: $(OBJS) $(TESTS) Makefile +test: $(TESTS) Makefile $(TARGET) bash ./unit-tests.sh .PHONY: clean diff --git a/src/arith/peano.h b/src/arith/peano.h index 163d47d..a7d63b3 100644 --- a/src/arith/peano.h +++ b/src/arith/peano.h @@ -15,12 +15,12 @@ /** * The maximum value we will allow in an integer cell. */ -#define MAX_INTEGER ((__int128_t)0x7fffffffffffffffL) +#define MAX_INTEGER ((__int128_t)0x0fffffffffffffffL) /** * @brief Number of value bits in an integer cell * */ -#define INTEGER_BITS 63 +#define INTEGER_BITS 60 bool zerop( struct cons_pointer arg ); diff --git a/state-of-play.md b/state-of-play.md index bd38ead..e96a15a 100644 --- a/state-of-play.md +++ b/state-of-play.md @@ -1,5 +1,23 @@ # State of Play +## 20250314 + +Thinking further about this, I think at least part of the problem is that I'm storing bignums as cons-space objects, which means that the integer representation I can store has to fit into the size of a cons pointer, which is 64 bits. Which means that to store integers larger than 64 bits I need chains of these objects. + +If I stored bignums in vector space, this problem would go away (especially as I have not implemented vector space yet). + +However, having bignums in vector space would cause a churn of non-standard-sized objects in vector space, which would mean much more frequent garbage collection, which has to be mark-and-sweep because unequal-sized objects, otherwise you get heap fragmentation. + +So maybe I just have to put more work into debugging my cons-space bignums. + +Bother, bother. + +There are no perfect solutions. + +However however, it's only the node that's short on vector space which has to pause to do a mark and sweep. It doesn't interrupt any other node, because their reference to the object will remain the same, even if it is the 'home node' of the object which is sweeping. So all the node has to do is set its busy flag, do GC, and clear its busy flag, The rest of the system can just be carrying on as normal. + +So... maybe mark and sweep isn't the big deal I think it is? + ## 20250313 OK, the 60 bit integer cell happens in `int128_to_integer` in `arith/integer.c`. It seems to be being done consistently; but there is no obvious reason. `MAX_INTEGER` is defined in `arith/peano.h`. I've changed both to use 63 bits, and this makes no change to the number of unit tests that fail.