{"id":"9930b3d5-bb6d-4b93-abb2-073539f1ecf1","arxiv_id":"2412.05286","paper_version":1,"verdict":"CONDITIONAL","confidence":"HIGH","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":3,"one_line_summary":"Simulated RISC-V custom modular instructions accelerate RNS modular multiplication by up to 2.76x over the best software-only reduction and by 4.5-8x fewer cycles than x86 in cycle counts.","lead":"This paper proposes three custom RISC-V instructions for word-size modular arithmetic (addmod, submod, mulmod) and evaluates them with GEM5 simulations. For RNS modular multiplication, the simulated speedups are large enough that chip designers may want to consider adding such instructions to RISC-V for cryptography and signal-processing workloads.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The headline speedups rest on unvalidated 2/4-cycle latencies for the proposed modular instructions; the paper's own long-delay case cuts the gain to 1.92x/2.30x, and a real mulmod datapath could be slower.","rationale":"The reader identified the most load-bearing assumption: the fixed hardware latencies of the custom modular instructions. I agree. The paper is transparent and internally consistent: it reports GEM5 simulation with explicit operator delays and includes a long-delay sensitivity analysis, so the central claim is not fabricated. However, the quantitative values in the abstract are stated without the latency caveat and are the main evidence for the claimed benefit. My stress test does not find a separate correctness flaw in the RNS algorithms or the comparison methodology; the main risk is that the instruction latencies are not hardware-validated, and the paper itself flags this in Section 5.4. No code or configuration artifacts are provided, so the exact GEM5 setup cannot be independently checked; this strengthens the conditional verdict but does not change it. I would keep the conditional verdict and ask for either an RTL measurement or a more detailed microarchitectural model before treating the headline speedups as hardware-realistic.","tokens_in":12079,"tokens_out":6049,"duration_ms":59437,"concrete_test":"Implement the three proposed instructions as a synthesizable RTL datapath in a RISC-V core (e.g., Rocket or a simple in-order core), including the third register-read port, and measure actual mulmod/addmod/submod latency and throughput at 1 GHz. Then rerun the GEM5 simulations of Table 2 with the measured latencies. If the measured mulmod latency is at most 4 cycles and addmod at most 2 cycles, the abstract's 2.76x/3.06x claims survive; if it is 9/4 or higher, the claims should be re-expressed using the paper's own long-delay ratios (1.92x/2.30x) or lower.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Section 4.4 fixes the modular adder and multiplier at 2 and 4 cycles (long-delay variant 4 and 9), and the GEM5 timing model simply attaches those latencies to the new instructions. Section 5.4 concedes \"they could be much longer in a real implementations.\" This assumption is load-bearing: the abstract's 2.76x (In Order) and 3.06x (Out of Order) speedups over pseudo-Mersenne are the ratios between a 4-cycle mulmod and a software reduction built from 3-cycle integer multiplications plus adds/shifts. The long-delay row of Table 2 shows that merely increasing mulmod to 9 cycles drops the ratios to 1.92x and 2.30x. A 64-bit reduction modulo an arbitrary run-time modulus is not a single-cycle or small fixed-latency operation; it requires either an iterative divider-like unit or a large Barrett multiplier, and the 4-operand encoding (rs1, rs2, rs3, rd) adds register-file read-port and bypass cost that GEM5 is not configured to model. If measured latency is above the assumed range, the instruction advantage can shrink below 1x. The claimed x86 ratios (4.5x/8x) are computed with the same unvalidated operator delays, so they share this sensitivity.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes three custom RISC-V instructions (addmod, submod, mulmod) for word-size modular arithmetic and evaluates their impact on sequential software implementations of RNS modular multiplication using the GEM5 simulator. It compares three word-size modulo methods (C compiled modulo, pseudo-Mersenne reduction, custom instructions) and two base-extension algorithms (Szabo-Tanaka and Kawamura) across in-order (Minor) and out-of-order (O3) models and channel counts from 8 to 64. The headline results are a 2.76x (in-order) and 3.06x (out-of-order) cycle-time speedup of the custom-instruction version over the best software-only implementation (pseudo-Mersenne with Kawamura base extension) and a 4.5x/8x advantage over x86, with a long-delay sensitivity case (mulmod=9, addmod=4) reducing those ratios to 1.92x/2.30x.","tokens_in":12355,"tokens_out":9008,"duration_ms":80970,"significance":"The paper addresses a real bottleneck in software RNS implementations and proposes a concrete, well-scoped ISA extension. Its strengths are the large simulation matrix, the inclusion of a long-delay sensitivity case, and the honest statement that the delays are assumed, not measured. If the assumed latencies are representative, the results strongly motivate future hardware support for word-size modular instructions. However, the central quantitative claims rest on unvalidated microarchitectural assumptions, and the paper does not model the full cost of the four-operand encoding or of a fused multiply-and-reduce datapath. The study is a useful simulation exploration, but the headline speedups should be treated as upper-bound estimates rather than validated performance.","major_comments":[{"comment":"The assumed latencies (mulmod=4, addmod=2; long-delay variant 9 and 4) are load-bearing for the headline speedups. As the paper itself notes in §5.4, 'they could be much longer in a real implementations.' The long-delay case in Table 1 shows the in-order speedup over pseudo-Mersenne falling from 2.76 to 1.92 and the out-of-order from 3.06 to 2.30. The manuscript does not model the extra pipeline costs of the four-operand encoding, such as an additional register-file read port, wider bypass network, or possible issue-width restrictions, and it does not provide a microarchitectural sketch of how a 64-bit multiply-and-reduce modulo an arbitrary runtime modulus could be completed in 4 cycles. Please add a more thorough sensitivity analysis, including a break-even latency, and qualify the abstract's numbers with the long-delay results or an explicit statement that the latency figures are optimistic assumptions.","section":"§4.4, §5.4, and Abstract"},{"comment":"The manuscript does not describe how the custom instructions were integrated into GEM5. It mentions adding them to gcc and checking with Spike, but no details are given about the GEM5 ISA description changes, execution unit configuration, and the timing model for the four-operand format. Without this information, the simulation results are not reproducible. Please include the relevant GEM5 modifications or provide a link to an artifact repository, so that the reported cycle counts can be independently verified.","section":"§4.1–§4.4"}],"minor_comments":[{"comment":"The description of the 'Modulo' baseline is ambiguous. The text says 'In case of processors without DIV instruction, i.e. our situation,' but it does not clarify whether the simulated RISC-V core implements the M extension. If DIV/REM is available, the C modulo operation would use a single REM instruction, which would make the large speedups over 'Modulo' harder to interpret. Please state the exact RISC-V ISA extensions enabled in the simulation.","section":"§4.3"},{"comment":"There is a typo in §5.3: 'Kaxamura' should be 'Kawamura'.","section":"§5.3"},{"comment":"The cross-references to 'Table 2' appear before the table is presented, and the table numbering is confusing because the first table in the text is also called 'Table 1.' Please renumber or restructure the table references for clarity.","section":"§5.2 and §5.3"},{"comment":"The abstract says '8 less' cycles; this should be '8 times fewer cycles.' In §5.4, 'in a real implementations' is a grammatical error.","section":"Abstract and §5.4"},{"comment":"Figure 1, showing the proposed instruction encodings, is difficult to read because the field boundaries and bit labels are small. A table or a more detailed figure with each field clearly labeled would improve readability.","section":"Figure 1"}],"recommendation":"major_revision","confidential_remarks":"The paper is a simulation-only study and the headline numbers are contingent on optimistic latency assumptions. The authors do include a long-delay sensitivity analysis, which is commendable, but they do not model the hardware cost of a four-operand encoding or of a fused multiply-modulo unit. In my view, the paper should be required to either provide a more realistic microarchitectural model or substantially qualify the claims. The contribution is interesting and within the scope of the journal, but the current presentation risks overstating the expected speedups on real hardware."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"This is a careful simulation study of a RISC-V custom extension for word-size modular arithmetic, applied to RNS modular multiplication. The headline speedups (2.76x in-order, 3.06x out-of-order over pseudo-Mersenne) are real within the simulated configuration, but they rest on assumed latencies of 2 cycles for addmod and 4 cycles for mulmod. The authors are honest about this: Section 5.4 says these delays “could be much longer in a real implementations,” and their long-delay variant (4 and 9 cycles) cuts the advantage to 1.87–2.74x. That is still a meaningful speedup, but it shows how sensitive the result is to the core assumption.\n\nWhat is new here is the systematic evaluation of these instructions across two base-extension methods (Kawamura and Szabo-Tanaka), in-order and out-of-order processor models, and RNS channel counts from 8 to 64. The comparison against pseudo-Mersenne moduli and the C modulo operator is fair, and the use of GEM5 with a real compiler toolchain gives the results concrete weight. The sensitivity analysis is the right thing to do, and it shows the ranking holds even if the operators are twice as slow.\n\nThe main soft spot is that the load-bearing latency numbers are assumed, not measured. A word-size mulmod for an arbitrary runtime modulus is not a 4-cycle operation in most designs; it likely requires a multi-cycle multiplier plus a reduction step, possibly a Barrett or division-like unit. The 4-operand encoding also adds register-file read-port and bypass pressure that GEM5 is not configured to model. If real silicon lands near the long-delay case, the advantage over pseudo-Mersenne is modest, and the x86 ratios (4.5x/8x) shrink accordingly. The paper also provides no code or GEM5 configuration artifacts, which makes independent reproduction harder—though that is fixable and not a conceptual flaw.\n\nThis paper is for readers working on RNS, RISC-V ISA extensions, or custom arithmetic datapaths. It is a useful feasibility study, not a hardware paper, and the authors correctly frame it as a prelude to implementation. The central claim holds within its own scope: the simulations show these speedups under clearly stated, admittedly optimistic assumptions.\n\nI would send it to peer review. The authors should be asked to supply artifacts and to be explicit that the speedups are conditional on the assumed operator delays. If a hardware prototype or a more detailed microarchitecture model later confirms the latencies, this becomes a stronger result.","headline":"Solid simulation study, but the headline speedups depend on unvalidated 2/4-cycle latencies for the custom modular instructions.","tokens_in":12866,"tokens_out":2539,"would_cite":false,"duration_ms":23603,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"This paper claims that adding word-size mulmod, addmod, and submod instructions to RISC-V makes software RNS modular multiplication up to 2.76x faster in-order and 3.06x out-of-order than pseudo-Mersenne moduli, and 4.5x to 8x faster than…","keywords":["Residue Number Systems","modular multiplication","RISC-V","word-size modular arithmetic","base extension","pseudo-Mersenne moduli","instruction set extension","cycle-level simulation"],"falsifier":"Measure a real 64-bit RISC-V implementation of mulmod/addmod/submod and rerun the 64-channel Kawamura-base-extension software: if the actual latencies approach or exceed the long-delay case (9 and 4 cycles) or force a pipeline stall for the extra register operand, the 2.76x/3.06x advantages over pseudo-Mersenne will not reproduce. A cheaper test is to re-run the same simulations with mulmod delay set above 9 cycles and addmod above 4 and observe the crossover point where pseudo-Mersenne wins.","tokens_in":11853,"feed_emoji":"🧮","tokens_out":8519,"duration_ms":75988,"temperature":0.7,"pith_summary":"This paper tries to show that the main obstacle to software Residue Number Systems (RNS) is the word-size modular reduction, and that RISC-V processors can remove that obstacle by adding three dedicated instructions: mulmod, addmod, and submod, each computing a result modulo a third register in one instruction. On cycle-level simulations of 64-bit In Order and Out of Order processors, the fastest configuration combines these instructions with Kawamura's base extension and beats the best software-only method (pseudo-Mersenne moduli) by a factor of 2.76 in-order and 3.06 out-of-order for 4096-bit modular multiplication. The same simulations show the instruction-equipped RISC-V completing the operation with 4.5 times fewer cycles than x86 in-order and 8 times fewer out-of-order, under matched cache, memory, and frequency settings. If the assumed hardware latencies are realistic, this would make RNS competitive in software on an open ISA, relevant to cryptography and signal processing.","feed_headline":"RISC-V modular instructions beat software RNS by 3x","feed_subtitle":"Simulated mulmod/addmod cut cycles 2.76x in-order and 3.06x out-of-order, beating x86 by up to 8x.","key_machinery":"The load-bearing mechanism is a three-input, one-output instruction format in the RISC-V custom-opcode space: mulmod rd, rs1, rs2, rs3 computes rd = (rs1 × rs2) mod rs3; addmod and submod do the same for addition and subtraction, using the third operand as the modulus. This turns the word-size modular reduction, normally a full division, into a single operation with fixed simulated latency (2 cycles for addmod, 4 for mulmod, or 4/9 in the long-delay case). The evaluation wraps these instructions around Algorithm 1, an RNS Montgomery modular multiplication with base extensions: the first conversion uses the approximate method from [9], and the second uses either Szabo-Tanaka or Kawamura's base extension, the latter estimating the CRT quotient k with O(n) word-size operations.","core_discovery":"The paper's central claim is that dedicated word-size modular arithmetic instructions change which RNS algorithm is best. With such instructions, the fastest implementation is RNS Montgomery modular multiplication that uses an approximate first base extension and Kawamura's approximate-quotient base extension for the second conversion: for 64 channels (4096-bit moduli) it runs in about 135,700 cycles in-order and 43,900 cycles out-of-order on the simulated RISC-V, versus about 342,400 and 134,100 cycles for pseudo-Mersenne moduli with the same base extension. The speedups are 2.76x and 3.06x, and the instruction version beats the simulated x86 baseline by 4.5x in-order and 8x out-of-order. The gain survives longer operator delays: with mulmod at 9 cycles and addmod at 4, the instruction version is still about 1.9x to 2.7x faster than pseudo-Mersenne in the configurations tested.","pith_inferences":["The paper does not quantify end-to-end cryptographic workloads, only the modular-multiplication kernel; applying the same instructions to the surrounding RNS conversions could shift the overall speedup for full RSA or ECC computations.","A real four-operand instruction needs an extra register-read port on the pipeline; if that port lengthens the cycle time or adds bypass delays, the cycle-count ratios shrink even though the instruction counts stay the same. A three-operand variant (e.g., reusing rd as the modulus) is a testable alternative the authors list as future work.","Because the gain is largest out-of-order, the results suggest RNS-friendly custom instructions are most valuable on superscalar RISC-V cores, and that a vector version of mulmod/addmod would let several RNS channels reduce simultaneously—an extension the paper plans but does not simulate."],"forward_implications":["On an in-order RISC-V core, the instruction-based implementation with Kawamura's base extension is 2.76x faster than the fastest pseudo-Mersenne implementation, making it the best configuration among those compared.","Out-of-order cores extract more from the instructions, reaching 3.06x, because independent RNS channels can issue in parallel.","Even if the modular units are slow (mulmod 9 cycles, addmod 4), the instruction version remains about 1.9x faster in-order and 2.3x to 2.7x faster out-of-order than pseudo-Mersenne reduction.","Against x86 with the same memory hierarchy and frequency, the simulated RISC-V with the new instructions needs 4.5x fewer cycles in-order and 8x fewer out-of-order for the 64-channel case."],"supporting_citations":[{"why":"Supplies the prior software comparison and RNS library that this work adapts and extends.","marker":"[14]"},{"why":"Introduces Kawamura's base extension, the approximate-quotient method used in the fastest configuration.","marker":"[23]"},{"why":"Gives the pseudo-Mersenne modular reduction, the software-only baseline that the instructions beat.","marker":"[31]"},{"why":"Provides the approximate first base extension used at step 3 of the RNS modular multiplication.","marker":"[9]"},{"why":"Is the cycle-level simulator used for all performance measurements of RISC-V and x86.","marker":"[10]"},{"why":"Is the Szabo-Tanaka base extension, the competing second-conversion method against Kawamura's.","marker":"[38]"},{"why":"Supplies the three-input register format that the new instructions reuse for their modulus operand.","marker":"[5]"},{"why":"Provides the RISC-V custom-opcode space that the proposed instructions occupy.","marker":"[44]"}],"fun_headline_variants":["RISC-V modular instructions speed RNS by 3x","Dedicated RNS instructions beat software by 3x on RISC-V","RNS gets 3x boost from RISC-V word-size mod instructions","RISC-V mod instructions outpace x86 by 8x in RNS","New RISC-V instructions make RNS multiplication 3x faster"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The entire comparison rests on the assumption that the new instructions can be implemented with the simulated latencies—4 cycles for mulmod and 2 for addmod—and that the four-operand encoding costs no extra pipeline delays; the paper acknowledges these delays could be longer in a real implementation.","fun_headline_variants_meta":{"raw":{"variants":["RISC-V modular instructions speed RNS by 3x","Dedicated RNS instructions beat software by 3x on RISC-V","RNS gets 3x boost from RISC-V word-size mod instructions","RISC-V mod instructions outpace x86 by 8x in RNS","New RISC-V instructions make RNS multiplication 3x faster"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000287,"raw_usage":{"total_tokens":1687,"prompt_tokens":945,"completion_tokens":742,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":561,"completion_tokens_details":{"reasoning_tokens":648}},"tokens_in":561,"tokens_out":742,"duration_ms":6871,"temperature":1.0,"reasoning_tokens":648,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-12T15:39:35.348953+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Measure a real 64-bit RISC-V implementation of mulmod/addmod/submod and rerun the 64-channel Kawamura-base-extension software: if the actual latencies approach or exceed the long-delay case (9 and 4 cycles) or force a pipeline stall for the extra register operand, the 2.76x/3.06x advantages over pseudo-Mersenne will not reproduce. A cheaper test is to re-run the same simulations with mulmod delay set above 9 cycles and addmod above 4 and observe the crossover point where pseudo-Mersenne wins.","supporting_citations":[{"cited_title":"A software comparison of RNS and PMNS","cited_arxiv_id":null,"evidence_quote":"Supplies the prior software comparison and RNS library that this work adapts and extends."},{"cited_title":"Cox- rower architecture for fast parallel montgomery multiplication","cited_arxiv_id":null,"evidence_quote":"Introduces Kawamura's base extension, the approximate-quotient method used in the fastest configuration."},{"cited_title":"Efficient word size modular arithmetic.IEEE Transactions on Emerging Topics in Computing, 9(3):1506–1518, 2021","cited_arxiv_id":null,"evidence_quote":"Gives the pseudo-Mersenne modular reduction, the software-only baseline that the instructions beat."},{"cited_title":"Bajard and L","cited_arxiv_id":null,"evidence_quote":"Provides the approximate first base extension used at step 3 of the RNS modular multiplication."},{"cited_title":"New York: McGraw-Hill, 1967","cited_arxiv_id":null,"evidence_quote":"Is the Szabo-Tanaka base extension, the competing second-conversion method against Kawamura's."},{"cited_title":"RISC-V \"V\" Vector Extension, Version 0.9-draft-1535cc0","cited_arxiv_id":null,"evidence_quote":"Supplies the three-input register format that the new instructions reuse for their modulus operand."},{"cited_title":"EECS Department, University of Cal- ifornia, Berkeley, 2019","cited_arxiv_id":null,"evidence_quote":"Provides the RISC-V custom-opcode space that the proposed instructions occupy."}],"review_version":1}