From info at mobile-stream.com Wed Nov 6 15:50:56 2019 From: info at mobile-stream.com (info at mobile-stream.com) Date: Wed, 06 Nov 2019 15:50:56 +0000 Subject: [PATCH 3 of 3][v2] Add RDHWR-based cycle counter module for MIPS32R2 In-Reply-To: <16691e684a95c822e376.1572796254@p5600> References: <16691e684a95c822e376.1572796254@p5600> Message-ID: Add RDHWR-based cycle counter module for MIPS32R2. OS must enable CC/CCRes bits for user-mode RDHWR to work so the code path is available on Linux only for now. NetBSD should be usable as well though. MIPS32R6 is omitted (though certainly compatible) as no testing was performed there. v2 limits the counter to linux as per mailing list discussion. diff -r 7423efa39db8 -r dcd5adde7731 configure.ac --- a/configure.ac +++ b/configure.ac @@ -1057,6 +1057,12 @@ esac ;; + mipsisa32r2*-*-linux*) + SPEED_CYCLECOUNTER_OBJ=mips32r2.lo + cyclecounter_size=1 + path="mips32/r1 mips32" + ;; + mipsisa32*-*-*) path="mips32/r1 mips32" ;; diff -r 7423efa39db8 -r dcd5adde7731 tune/Makefile.am --- a/tune/Makefile.am +++ b/tune/Makefile.am @@ -33,7 +33,7 @@ AM_LDFLAGS = -no-install EXTRA_DIST = alpha.asm pentium.asm sparcv9.asm hppa.asm hppa2.asm hppa2w.asm \ - ia64.asm powerpc.asm powerpc64.asm x86_64.asm many.pl + ia64.asm powerpc.asm powerpc64.asm x86_64.asm mips32r2.asm many.pl noinst_HEADERS = speed.h # Prefer -static on the speed and tune programs, since that can avoid diff -r 7423efa39db8 -r dcd5adde7731 tune/mips32r2.asm --- /dev/null +++ b/tune/mips32r2.asm @@ -0,0 +1,12 @@ +include(`../config.m4') + +ASM_START() +PROLOGUE(speed_cyclecounter) + rdhwr $2,$2 + slti $3,$2,0 + sll $2,$2,1 C save multiply and assume CCRes is 2 + sw $3,4($4) + jr $ra + sw $2,0($4) +EPILOGUE(speed_cyclecounter) +ASM_END() From info at mobile-stream.com Wed Nov 6 15:50:54 2019 From: info at mobile-stream.com (info at mobile-stream.com) Date: Wed, 06 Nov 2019 15:50:54 +0000 Subject: [PATCH 1 of 3][v2] Provide c/l table for some MIPS32 CPUs Message-ID: <16691e684a95c822e376.1572796254@p5600> Provide c/l table for some MIPS32 CPUs. v2 adds 74Kc results. diff -r 688b91c9b765 -r 16691e684a95 mpn/mips32/addmul_1.asm --- a/mpn/mips32/addmul_1.asm +++ b/mpn/mips32/addmul_1.asm @@ -31,6 +31,14 @@ include(`../config.m4') +C cycles/limb +C 4KEc 16.33 +C 24Kc 18.04 +C 24KEc 18.05 +C 74Kc 12.04 +C P5600 9.05 +C XBurst 17.05 + C INPUT PARAMETERS C res_ptr $4 C s1_ptr $5 diff -r 688b91c9b765 -r 16691e684a95 mpn/mips32/mul_1.asm --- a/mpn/mips32/mul_1.asm +++ b/mpn/mips32/mul_1.asm @@ -31,6 +31,14 @@ include(`../config.m4') +C cycles/limb +C 4KEc 12.22 +C 24Kc 14.03 +C 24KEc 14.05 +C 74Kc 9.04 +C P5600 7.05 +C XBurst 13.05 + C INPUT PARAMETERS C res_ptr $4 C s1_ptr $5 diff -r 688b91c9b765 -r 16691e684a95 mpn/mips32/submul_1.asm --- a/mpn/mips32/submul_1.asm +++ b/mpn/mips32/submul_1.asm @@ -31,6 +31,14 @@ include(`../config.m4') +C cycles/limb +C 4KEc 16.33 +C 24Kc 18.04 +C 24KEc 18.05 +C 74Kc 12.04 +C P5600 9.05 +C XBurst 17.05 + C INPUT PARAMETERS C res_ptr $4 C s1_ptr $5 From info at mobile-stream.com Wed Nov 6 15:50:55 2019 From: info at mobile-stream.com (info at mobile-stream.com) Date: Wed, 06 Nov 2019 15:50:55 +0000 Subject: [PATCH 2 of 3][v2] Add MADDU-based *mul_1.asm functions for MIPS32R1+ In-Reply-To: <16691e684a95c822e376.1572796254@p5600> References: <16691e684a95c822e376.1572796254@p5600> Message-ID: <7423efa39db80f53c523.1572796255@p5600> Add MADDU-based *mul_1.asm implementation for MIPS32R1. It is faster on all tried MIPS32R1/R2/R5 CPUs (see the c/l table) and is expected to be fast with any pipelined MDU. Note the Area-Efficient MDU (an optional non-pipelined Multiply-Divide Unit available for some MIPS cores and MCUs) will run it much slower though (~3x for addmul_1). The code tries to keep the [accidental] property of MIPS-II counterparts: constant-time operation on 32x16 MDUs as found on e.g. 4KEc and some low- end MCUs. Even if this is unimportant, the performance cost is invisible. While functions look similar (especially mul_1 and addmul_1), they are kept separate due to corner-case (N=1,2,3) tweaks for P5600 without any ill effect on 4KEc or 24KEc at least. v2 improves addmul_1 on P5600 to more natural ~7.5 c/l and adds 74Kc c/l. diff -r 16691e684a95 -r 7423efa39db8 configure.ac --- a/configure.ac +++ b/configure.ac @@ -1055,7 +1055,10 @@ path_64="mips64/hilo mips64" ;; esac - + ;; + + mipsisa32*-*-*) + path="mips32/r1 mips32" ;; esac ;; diff -r 16691e684a95 -r 7423efa39db8 mpn/mips32/r1/addmul_1.asm --- /dev/null +++ b/mpn/mips32/r1/addmul_1.asm @@ -0,0 +1,80 @@ +include(`../config.m4') + +C cycles/limb +C 4KEc 9.68 +C 24Kc 9.52 +C 24KEc 9.55 +C 74Kc 7.05 +C P5600 7.57 +C XBurst 13.55 + +C INPUT PARAMETERS +C rp $a0 +C up $a1 +C n $a2 +C vl $a3 + +ASM_START() + .set noat +PROLOGUE(mpn_addmul_1) + lw $v1,0($a1) C L0 + ori $at,$zero,1 + multu $v1,$a3 C M0 + lw $t0,0($a0) C L1, 32x16 MDU stall + addiu $t1,$a2,-2 + beq $at,$a2,1f + maddu $t0,$at C M0 + mfhi $v0 C M0 carry + lw $t2,4($a1) C L1 + beqz $t1,23f + lw $v1,4($a0) C L1 + mflo $t0 C M0 + andi $t3,$t1,1 + sll $a2,$t1,2 + beqz $t3,0f + addu $a2,$a2,$a1 + multu $t2,$a3 C M1 + lw $t2,8($a1) C L2, 32x16 MDU stall + maddu $v1,$at C M1 + maddu $v0,$at C M1 + mfhi $v0 C M1 carry + lw $v1,8($a0) C L2 + sw $t0,0($a0) C S0 + beq $at,$t1,23f + addiu $a0,$a0,4 + addiu $a1,$a1,4 + mflo $t0 C M1 +0: addiu $a1,$a1,8 + addiu $a0,$a0,8 + multu $t2,$a3 C M1 + lw $t3,0($a1) C L2, 32x16 MDU stall + maddu $v1,$at C M1 + lw $t4,0($a0) C L2 + maddu $v0,$at C M1 + mfhi $v0 C M1 carry + sw $t0,-8($a0) C S0 + mflo $t1 C M1 + multu $t3,$a3 C M2 + lw $t2,4($a1) C L3, 32x16 MDU stall + maddu $t4,$at C M2 + lw $v1,4($a0) C L3 + maddu $v0,$at C M2 + sw $t1,-4($a0) C S1 + mfhi $v0 C M2 carry + bne $a1,$a2,0b +23: mflo $t0 C M2 + multu $t2,$a3 C M3 + nop C 32x16 MDU stall + maddu $v1,$at C M3 + maddu $v0,$at C M3 + mflo $at C M3 + mfhi $v0 C M3 carry + sw $t0,0($a0) C S2 + jr $ra + sw $at,4($a0) C S3 +1: mflo $at + mfhi $v0 + jr $ra + sw $at,0($a0) +EPILOGUE(mpn_addmul_1) +ASM_END() diff -r 16691e684a95 -r 7423efa39db8 mpn/mips32/r1/mul_1.asm --- /dev/null +++ b/mpn/mips32/r1/mul_1.asm @@ -0,0 +1,70 @@ +include(`../config.m4') + +C cycles/limb +C 4KEc 7.66 +C 24Kc 7.54 +C 24KEc 7.55 +C 74Kc 7.04 +C P5600 7.04 +C XBurst 10.54 + +C INPUT PARAMETERS +C rp $a0 +C up $a1 +C n $a2 +C vl $a3 + +ASM_START() + .set noat +PROLOGUE(mpn_mul_1) + lw $v1,0($a1) C L0 + ori $at,$zero,1 + multu $v1,$a3 C M0 + beq $at,$a2,1f C 32x16 MDU stall + addiu $t1,$a2,-2 + mfhi $v0 C M0 carry + beqz $t1,23f + lw $t2,4($a1) C L1 + mflo $t0 C M0 + andi $t3,$t1,1 + sll $a2,$t1,2 + beqz $t3,0f + addu $a2,$a2,$a1 + multu $t2,$a3 C M1 + lw $t2,8($a1) C L2, 32x16 MDU stall + maddu $v0,$at C M1 + mfhi $v0 C M1 carry + sw $t0,0($a0) C S0 + beq $at,$t1,23f + addiu $a0,$a0,4 + addiu $a1,$a1,4 + mflo $t0 C M1 +0: addiu $a1,$a1,8 + addiu $a0,$a0,8 + multu $t2,$a3 C M1 + lw $t3,0($a1) C L2, 32x16 MDU stall + maddu $v0,$at C M1 + mfhi $v0 C M1 carry + sw $t0,-8($a0) C S0 + mflo $t1 C M1 + multu $t3,$a3 C M2 + lw $t2,4($a1) C L3, 32x16 MDU stall + maddu $v0,$at C M2 + mfhi $v0 C M2 carry + sw $t1,-4($a0) C S1 + bne $a1,$a2,0b +23: mflo $t0 C M2 + multu $t2,$a3 C M3 + nop C 32x16 MDU stall + maddu $v0,$at C M3 + mflo $at C M3 + mfhi $v0 C M3 carry + sw $t0,0($a0) C S2 + jr $ra + sw $at,4($a0) C S3 +1: mflo $at + mfhi $v0 + jr $ra + sw $at,0($a0) +EPILOGUE(mpn_mul_1) +ASM_END() diff -r 16691e684a95 -r 7423efa39db8 mpn/mips32/r1/submul_1.asm --- /dev/null +++ b/mpn/mips32/r1/submul_1.asm @@ -0,0 +1,86 @@ +include(`../config.m4') + +C cycles/limb +C 4KEc 10.72 +C 24Kc 10.54 +C 24KEc 10.55 +C 74Kc 9.04 +C P5600 8.07 +C XBurst 13.55 + +C INPUT PARAMETERS +C rp $a0 +C up $a1 +C n $a2 +C vl $a3 + +ASM_START() + .set noat +PROLOGUE(mpn_submul_1) + lw $v1,0($a0) C L1 + ori $at,$zero,1 + lw $t0,0($a1) C L0 + multu $v1,$at C M0 + msubu $t0,$a3 C M0 + beq $at,$a2,1f C 32x16 MDU stall + addiu $t1,$a2,-2 + mfhi $v0 C M0 carry + lw $v1,4($a0) C L1 + beqz $t1,23f + lw $t2,4($a1) C L1 + mflo $t0 C M0 + andi $t3,$t1,1 + sll $a2,$t1,2 + beqz $t3,0f + addu $a2,$a2,$a1 + negu $v0 C M1 + multu $v1,$at C M1 + msubu $t2,$a3 C M1 + addiu $a0,$a0,4 C 32x16 MDU stall + msubu $v0,$at C M1 + mfhi $v0 C M1 carry + lw $v1,4($a0) C L2 + lw $t2,8($a1) C L2 + beq $at,$t1,23f + sw $t0,-4($a0) C S0 + addiu $a1,$a1,4 + mflo $t0 C M1 +0: addiu $a0,$a0,8 + addiu $a1,$a1,8 + multu $v1,$at C M1 + lw $t4,0($a0) C L2 + lw $t3,0($a1) C L2 + msubu $t2,$a3 C M1 + negu $v0 C M1, 32x16 MDU stall + msubu $v0,$at C M1 + mfhi $v0 C M1 carry + sw $t0,-8($a0) C S0 + mflo $t1 C M1 + multu $t4,$at C M2 + lw $v1,4($a0) C L3 + lw $t2,4($a1) C L3 + msubu $t3,$a3 C M2 + negu $v0 C M2, 32x16 MDU stall + msubu $v0,$at C M2 + mfhi $v0 C M2 carry + sw $t1,-4($a0) C S1 + bne $a1,$a2,0b +23: mflo $t0 C M2 + multu $v1,$at C M3 + msubu $t2,$a3 C M3 + negu $v0 C M3, 32x16 MDU stall + sw $t0,0($a0) C S2 + msubu $v0,$at C M3 + mflo $at C M3 + mfhi $v0 C M3 carry + sw $at,4($a0) C S3 + jr $ra + negu $v0 +1: mflo $at + mfhi $v0 + sw $at,0($a0) + jr $ra + negu $v0 +EPILOGUE(mpn_submul_1) + +ASM_END() From borucki.andrzej at gmail.com Sat Nov 9 14:34:57 2019 From: borucki.andrzej at gmail.com (Andy) Date: Sat, 9 Nov 2019 15:34:57 +0100 Subject: odd using of macro MODLIMB_INVERSE_3 Message-ID: In file toom_interpolate_6pts.c is: /* For odd divisors, mpn_divexact_1 works fine with two's complement. */ #ifndef mpn_divexact_by3 #if HAVE_NATIVE_mpn_pi1_bdiv_q_1 && MODLIMB_INVERSE_3 #define mpn_divexact_by3(dst,src,size) mpn_pi1_bdiv_q_1(dst,src,size,3,MODLIMB_INVERSE_3,0) #else #define mpn_divexact_by3(dst,src,size) mpn_divexact_1(dst,src,size,3) #endif #endif This can make some problems on some compilers. if I have correctly guessed the intentions of this conditional, it doesn't matter what the value is MODLIMB_INVERSE_3 but if is defined, should be . #if HAVE_NATIVE_mpn_pi1_bdiv_q_1 && defined MODLIMB_INVERSE_3 ? From bodrato at mail.dm.unipi.it Sat Nov 9 16:32:08 2019 From: bodrato at mail.dm.unipi.it (Marco Bodrato) Date: Sat, 09 Nov 2019 17:32:08 +0100 Subject: odd using of macro MODLIMB_INVERSE_3 In-Reply-To: References: Message-ID: <1f44db2141ce4f0630d30f101ece5633@student.dm.unipi.it> Ciao, Il 2019-11-09 15:34 Andy ha scritto: > In file toom_interpolate_6pts.c is: > #ifndef mpn_divexact_by3 > #if HAVE_NATIVE_mpn_pi1_bdiv_q_1 && MODLIMB_INVERSE_3 > This can make some problems on some compilers. > if I have correctly guessed the intentions of this conditional, it > doesn't > matter what the value is MODLIMB_INVERSE_3 but if is defined, Currently, MODLIMB_INVERSE_3 is always defined, so we shall get rid of the && MODLIMB_INVERSE_3 condition. I believe that also mpn_divexact_by3 is always defined with the current library. So we should probably get rid of all the #ifndef ... ?is, m -- http://bodrato.it/papers/ From bodrato at mail.dm.unipi.it Sat Nov 9 17:22:56 2019 From: bodrato at mail.dm.unipi.it (Marco Bodrato) Date: Sat, 09 Nov 2019 18:22:56 +0100 Subject: odd using of macro MODLIMB_INVERSE_3 In-Reply-To: <1f44db2141ce4f0630d30f101ece5633@student.dm.unipi.it> References: <1f44db2141ce4f0630d30f101ece5633@student.dm.unipi.it> Message-ID: <2ed6a5c2fe105b276b841b05f26b4642@student.dm.unipi.it> Ciao, > Il 2019-11-09 15:34 Andy ha scritto: >> In file toom_interpolate_6pts.c is: > >> #ifndef mpn_divexact_by3 >> #if HAVE_NATIVE_mpn_pi1_bdiv_q_1 && MODLIMB_INVERSE_3 > >> This can make some problems on some compilers. I decided for the easiest solution: using in _6pts the same code used by _7pts and _8pts. https://gmplib.org/repo/gmp/rev/dc44b59ee8db ?is, m From nisse at lysator.liu.se Sun Nov 10 08:43:10 2019 From: nisse at lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) Date: Sun, 10 Nov 2019 09:43:10 +0100 Subject: Small limb-size in mini-gmp? Message-ID: Hi, I noticed the recent change https://gmplib.org/repo/gmp/rev/d5f4f8640be9, "mini-gmp: Avoid undefined behaviour with small limb sizes." Currently, mini-gmp.h makes mp_limb_t an alias for unsigned long, which by the C spec ought to be at least 32 bits. And then, e.g., int LOCAL_SHIFT_BITS = 16; ... if (sizeof(mp_limb_t) * CHAR_BIT > LOCAL_SHIFT_BITS) ought to be always true. Are you planning to do something like artificial-small-limbs for mini-gmp, suggested on the list a while ago? Also, if (GMP_LIMB_BITS > LOCAL_SHIFT_BITS) should be equivalent, and slightly more readable, imo. Regards, /Niels -- Niels M?ller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. From bodrato at mail.dm.unipi.it Sun Nov 10 11:02:07 2019 From: bodrato at mail.dm.unipi.it (Marco Bodrato) Date: Sun, 10 Nov 2019 12:02:07 +0100 Subject: Small limb-size in mini-gmp? In-Reply-To: References: Message-ID: <7fd2293a0c15cf402363223fe22daa44@student.dm.unipi.it> Ciao Niels! Il 2019-11-10 09:43 nisse at lysator.liu.se ha scritto: > I noticed the recent change > https://gmplib.org/repo/gmp/rev/d5f4f8640be9, "mini-gmp: Avoid > undefined > behaviour with small limb sizes." > Are you planning to do something like artificial-small-limbs > for mini-gmp, suggested on the list a while ago? The current code should work smoothly if you change mini-gmp.h and typedef unsigned char mp_limb_t; or use others unsigned types. Hopefully, both larger and smaller than the default unsigned long should work. It works thanks to the last corrections and to the work done last year after the discussion on Paul's micro-gmp. Paul also asked us "to indicate in mini-gmp.h the places to modify" (https://gmplib.org/list-archives/gmp-devel/2018-December/005123.html) and you proposed a possible syntax in https://gmplib.org/list-archives/gmp-devel/2018-December/005126.html But I'm not sure we should officially document this feature, for the simple reason that... it is not currently tested by our great testing framework. So, I'm not "planning" anything more that what was already done. Except possibly enabling an easy way to test the code with 8, 16, 32-bits types... But it is not a priority for me, at the moment. Maybe it works also for artificialy-small-limbs, maybe not. I did not try, and I'm not planning any other change to support them. > Also, > > if (GMP_LIMB_BITS > LOCAL_SHIFT_BITS) > > should be equivalent, and slightly more readable, imo. I agree! Adopted. ?is, m From bodrato at mail.dm.unipi.it Sun Nov 10 11:32:20 2019 From: bodrato at mail.dm.unipi.it (Marco Bodrato) Date: Sun, 10 Nov 2019 12:32:20 +0100 Subject: Small limb-size in mini-gmp? In-Reply-To: <7fd2293a0c15cf402363223fe22daa44@student.dm.unipi.it> References: <7fd2293a0c15cf402363223fe22daa44@student.dm.unipi.it> Message-ID: <3a2e64d4f0903b231c44b8a740260f14@student.dm.unipi.it> PS: Il 2019-11-10 12:02 Marco Bodrato ha scritto: > It works thanks to the last corrections and to the work done last year > after the discussion on Paul's micro-gmp. e.g.: https://gmplib.org/repo/gmp/rev/3f1afa83957e ?is, m From borucki.andrzej at gmail.com Sat Nov 9 16:49:43 2019 From: borucki.andrzej at gmail.com (Andy) Date: Sat, 9 Nov 2019 17:49:43 +0100 Subject: #ifdef HAVE_NATIVE_NNN Message-ID: Small note and fast applicable: Mabe better than "#ifdef HAVE_NATIVE" always should be "#if HAVE_NATIVE" because user can freely in this case for example #define HAVE_NATIVE_mpn_rsh1sub_n 0 without delete this line? From borucki.andrzej at gmail.com Sun Nov 10 17:04:34 2019 From: borucki.andrzej at gmail.com (Andy) Date: Sun, 10 Nov 2019 18:04:34 +0100 Subject: Half of limb works only in 64 limb in divexact? Message-ID: In mpn_divexact_1 and umul_ppmm_lowequal is constant 32 bits instead of half bits. From tg at gmplib.org Tue Nov 12 13:05:22 2019 From: tg at gmplib.org (=?utf-8?Q?Torbj=C3=B6rn?= Granlund) Date: Tue, 12 Nov 2019 14:05:22 +0100 Subject: Small limb-size in mini-gmp? In-Reply-To: <7fd2293a0c15cf402363223fe22daa44@student.dm.unipi.it> (Marco Bodrato's message of "Sun, 10 Nov 2019 12:02:07 +0100") References: <7fd2293a0c15cf402363223fe22daa44@student.dm.unipi.it> Message-ID: <868sol6y99.fsf@shell.gmplib.org> Marco Bodrato writes: But I'm not sure we should officially document this feature, for the simple reason that... it is not currently tested by our great testing framework. I'd be willing to add whatever test is desirable. (Editing the mp_limb_t declaration from within the test drivers might be a poor approach, though, so I'll wait until there is a defined method of controlling its declaration.) -- Torbj?rn Please encrypt, key id 0xC8601622 From nisse at lysator.liu.se Tue Nov 12 15:25:54 2019 From: nisse at lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) Date: Tue, 12 Nov 2019 16:25:54 +0100 Subject: Small limb-size in mini-gmp? In-Reply-To: <868sol6y99.fsf@shell.gmplib.org> (=?utf-8?Q?=22Torbj=C3=B6rn?= Granlund"'s message of "Tue, 12 Nov 2019 14:05:22 +0100") References: <7fd2293a0c15cf402363223fe22daa44@student.dm.unipi.it> <868sol6y99.fsf@shell.gmplib.org> Message-ID: tg at gmplib.org (Torbj?rn Granlund) writes: > (Editing the mp_limb_t declaration from within the test drivers might be > a poor approach, though, so I'll wait until there is a defined method of > controlling its declaration.) Then we'd need something like #ifndef MINI_GMP_LIMB_TYPE #define MINI_GMP_LIMB_TYPE unsigned long #endif typedef MINI_GMP_LIMB_TYPE mp_limb_t in mini-gmp.h. Is there any simpler or prettier way? One could do it in two lines less as #ifndef mp_limb_t typedef unsigned long mp_limb_t #endif (leaving to the overriding code to define the type) but I'm not sure I like that better. Regards, /Niels -- Niels M?ller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. From bodrato at mail.dm.unipi.it Tue Nov 12 21:22:00 2019 From: bodrato at mail.dm.unipi.it (Marco Bodrato) Date: Tue, 12 Nov 2019 22:22:00 +0100 Subject: Small limb-size in mini-gmp? In-Reply-To: References: <7fd2293a0c15cf402363223fe22daa44@student.dm.unipi.it> <868sol6y99.fsf@shell.gmplib.org> Message-ID: <70e5629dcc0dadd692ecf5f17b88ecd0@student.dm.unipi.it> Il 2019-11-12 16:25 nisse at lysator.liu.se ha scritto: > tg at gmplib.org (Torbj?rn Granlund) writes: >> so I'll wait until there is a defined method of >> controlling its declaration.) > Then we'd need something like > > #ifndef MINI_GMP_LIMB_TYPE > #define MINI_GMP_LIMB_TYPE unsigned long > #endif > > typedef MINI_GMP_LIMB_TYPE mp_limb_t > > in mini-gmp.h. Seems clean and straightforward. Is something like the following too tricky? #ifndef MINI_GMP_LIMB_TYPE #define MINI_GMP_LIMB_TYPE long #endif typedef unsigned MINI_GMP_LIMB_TYPE mp_limb_t As only unsigned types are supported... Then, should we adapt the Makefile target check-mini-gmp in such a way that it can handle make MINI_GMP_LIMB_TYPE=char check-mini-gmp ? ?is, m From tg at gmplib.org Tue Nov 12 21:23:45 2019 From: tg at gmplib.org (=?utf-8?Q?Torbj=C3=B6rn?= Granlund) Date: Tue, 12 Nov 2019 22:23:45 +0100 Subject: Small limb-size in mini-gmp? In-Reply-To: <70e5629dcc0dadd692ecf5f17b88ecd0@student.dm.unipi.it> (Marco Bodrato's message of "Tue, 12 Nov 2019 22:22:00 +0100") References: <7fd2293a0c15cf402363223fe22daa44@student.dm.unipi.it> <868sol6y99.fsf@shell.gmplib.org> <70e5629dcc0dadd692ecf5f17b88ecd0@student.dm.unipi.it> Message-ID: <8636eseqla.fsf@shell.gmplib.org> Marco Bodrato writes: Seems clean and straightforward. Is something like the following too tricky? #ifndef MINI_GMP_LIMB_TYPE #define MINI_GMP_LIMB_TYPE long #endif typedef unsigned MINI_GMP_LIMB_TYPE mp_limb_t As only unsigned types are supported... Then, should we adapt the Makefile target check-mini-gmp in such a way that it can handle make MINI_GMP_LIMB_TYPE=char check-mini-gmp Avoiding a space in the type would help. :-) -- Torbj?rn Please encrypt, key id 0xC8601622