Pith. sign in

REVIEW 3 major objections 5 minor 12 references

FREESS: An Educational Simulator of a RISC-V-Inspired Superscalar Processor Based on Tomasulo's Algorithm

T0 review · 3 major / 5 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read This paper claims FREESS gives students a cycle-accurate, paper-traceable view of a Tomasulo-based superscalar processor, backed by three worked examples and a configurable open-source simulator.

desk verdict A genuinely useful teaching simulator whose central 'cycle-accurate' claim is plausible but unverified; worth reviewing with a request for a test suite. read the letter →

arxiv 2506.07665 v1 pith:CW2MLMGP submitted 2025-06-09 cs.AR

Roberto Giorgi This is my paper
classification cs.AR
keywords superscalarprocessorTomasulo'salgorithmout-of-orderexecutioneducationalsimulatorRISC-Vregisterrenamingreorderbufferinstruction-levelparallelism
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper presents FREESS, a command-line simulator that claims to provide a cycle-accurate view of the key hardware structures of a RISC-V-inspired superscalar processor built on an extended Tomasulo algorithm. The goal is pedagogical: students watch fetch, rename, dispatch, issue, execute, write-back, and commit for tiny programs while seeing the Instruction Window, Register Map, Free Pool, Reorder Buffer, and Load/Store Queues update every cycle. The simulator is designed so its entire textual output can be replicated on a single sheet of paper, letting students verify by hand what the machine does. If the claim is right, FREESS gives advanced computer-architecture courses a lightweight, open, configurable tool for teaching out-of-order execution and understanding stall causes.

What carries the argument

The central object is the single-screen, cycle-by-cycle textual state display driven by an extended Tomasulo algorithm—rename registers through a free pool, issue instructions as soon as their source values are ready, and commit in program order through a reorder buffer. Each instruction carries a dynamic program counter and records the cycle it enters F (fetch), D (decode/rename), P (dispatch), I (issue), X (execute), W (write-back), and C (commit); alongside it, the screen shows the register map and free pool, the instruction window slots with source-ready flags, the ROB slots with old-physical-register and completion flags, the load/store queues, and a set of stall counters. These structures together determine when instructions issue, write back, and commit, and the printed state is meant to match what a student could write on paper.

What would settle it

Hand-trace Example 1 on paper and compare it cycle by cycle with the printed output: if any IW-slot readiness flag, ROB completion flag, or stall counter disagrees with the documented Tomasulo semantics—or if the final reported IPC is not 1.05 over 20 cycles—the simulator does not provide the claimed cycle-accurate view.

Watch

Extended reading notes

Core claim

FREESS claims that a superscalar machine's dynamic behavior—how instructions flow through an out-of-order pipeline and how architectural resources are consumed—can be captured on a single text screen and traced by hand. The simulator models seven RISC-V-like instructions (ADD, ADDI, BEQ, BNE, LW, MUL, SW), assumes branches are speculatively taken, and shows each cycle the state of physical registers, the register map, the free pool, the instruction window, the ROB, the load/store queues, and stall counters. Its three worked examples report concrete results: a 21-instruction vector loop yields 1.05 IPC over 20 cycles in the default 4-way configuration, a shorter five-instruction loop reaches 1.36 IPC with a 12-slot window, and the same loop on a 2-way machine drops to 1.07 IPC with identical total stalls. The author's main claim is that this provides a cycle-accurate visualization of the key Tomasulo structures, making dynamic scheduling teachable by direct observation and manual verification.

Load-bearing premise

Everything rests on the unverified premise that the simulator's C implementation actually behaves as described—that the register map, free pool, instruction window, ROB, load/store queues, branch speculation, and stall counters all follow the intended Tomasulo semantics exactly.

Editorial extensions

If this is right

  • Students can verify a full superscalar trace by hand: the on-screen layout is designed to match a paper worksheet, so a traced solution can be compared cycle by cycle with the simulator.
  • Configurable widths and latencies let an instructor generate fresh exercises and let students see the direct effect of dispatch width, issue width, window size, and functional-unit counts on IPC and on where stalls occur.
  • The stall log and per-stage counters turn bottleneck analysis into a concrete exercise: students can identify whether a stall is structural, data, or control related by reading the logged cycle and reason.
  • The three prebuilt examples give reproducible baselines (IPC 1.05, 1.36, and 1.07) that a correctly implemented simulator should reproduce, supporting self-checking during coursework.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If the simulator's semantics are correct, the same engine could serve as a reference model for validating student-written Tomasulo implementations, since every internal structure is printed each cycle.
  • Because branches are assumed always taken, the tool presently illustrates misspeculation rollback only through ROB state and saved old physical registers; adding a configurable predictor would let students study prediction accuracy without changing the core teaching loop.
  • The minimal seven-instruction ISA and manual opcode entry could naturally extend toward deeper memory-hierarchy effects, such as store-to-load forwarding, while keeping the single-screen teaching interface intact.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. The paper presents FREESS, an educational C simulator of a RISC-V-inspired superscalar processor implementing a Tomasulo-based dynamic scheduling algorithm. The tool models fetch, rename, dispatch, issue, execute, write-back, commit, and branch speculation, with configurable widths, buffer sizes, and latencies. The paper describes the tool's parameters and screen layout, walks through a first example in detail, reports IPC and stall statistics for two further examples, and gives an informal account of classroom use since 2010. The stated contributions are a paper-and-pencil teaching methodology aligned with a single-screen cycle-by-cycle view, a 'cycle-accurate' simulator, and an open-source release.

Significance. FREESS addresses a real pedagogical gap with a single-screen, text-based visualization that students can reproduce on paper, and it is implemented in a compact, portable C codebase (~2000 lines) with three runnable examples. The open-source repository and command-line configuration are practical strengths. If the simulator's behavior is correct, the three examples provide useful reference exercises and the reported IPC/stall statistics are plausible teaching material. However, the paper does not itself establish that correctness, and the educational-impact evidence is anecdotal, leaving the two central claims only partially supported.

major comments (3)
  1. [§1 Contributions; §3.3] The central claim that FREESS 'provides a cycle-accurate view' (Contributions, §1) is not verified by any independent reference. The only evidence for correctness is the simulator's own screenshots (e.g., Fig. 2, 7-11, 14-15) and the repository URL in Appendix A. Because the proposed teaching method assumes students can reproduce the trace on paper, a bug in the ~2000-line C code would silently propagate incorrect dynamic-scheduling semantics. I recommend adding to the repository a golden-trace test suite for the three examples, with per-cycle states of the RM, FP, IW, ROB, LQ/SQ, and stall counters, and a statement of how these traces were validated (hand trace or independent reference model).
  2. [§5 Impact] The educational-effectiveness claim ('effective teaching tool', Abstract and §5) rests on anecdotal self-reports ('students consistently report feeling more confident') and 15 years of classroom use, with no student-performance data, no comparison with a control condition or alternative tool, and no analysis of exam results. Since this is one of the two stated contributions, please provide quantitative evidence (e.g., pre/post test scores, pass rates on manual-trace exercises) or temper the claim to 'anecdotal classroom experience suggests promise.'
  3. [§3.2, §3.3.2] The instruction encoding and branch-redirect policy are underspecified, preventing independent verification of the IPC and stall counts. In §3.2 the machine-code lines (e.g., '1 3 4 0') do not define the field order, and the branch immediate is described only as 'the number of instructions to jump' without stating whether the target is PC+4+imm or PC+imm, or when the fetch is redirected (decode vs. branch resolution). §3.3.2 says the branch 'forces the fetch stage to break fetching,' but no cycle is given for the redirect. Please add a precise encoding table and a worked branch-target calculation for the Example-1 loop so that the reported trace (IPC 1.05, 20 cycles) can be reproduced.
minor comments (5)
  1. [§2] Reference [1] appears as 'SIMDE [1]]' with a duplicate closing bracket.
  2. [§1] 'adoptsuperscalar' is missing a space and should read 'adopts superscalar'.
  3. [§4.1] The sentence 'In the first example (Fig. 13), we got 9 stalls...' cites Fig. 13, which is the auto-generated text for Example-2, not the first example; the stall counts presumably refer to Example-1 in Fig. 9 or Fig. 11.
  4. [§3.3.4] 'Ci indicates the cycle when the reload is queued' should likely read 'when the load is queued'.
  5. [References] Reference [5] formatting: 'InICS’24' should be 'In ICS’24'.

Circularity Check

0 steps flagged · score 0.0 of 10

No circular derivation: the simulator outputs are generated evidence, not fitted inputs, and the sole self-citation is contextual.

full rationale

The paper does not fit any parameter to a target, does not define a quantity in terms of the quantity it is supposed to predict, and does not import a load-bearing premise from a self-citation. The reported IPC, cycle counts, and stall statistics are outputs of the FREESS C code, not inputs chosen to reproduce a target result. The only self-citation, WebRISC-V (ref [6]), appears in Related Work as a contrast example of other RISC-V pipeline simulators and is not used to justify the correctness of FREESS. The central claim of a cycle-accurate Tomasulo view is supported by the tool's own screen captures; no independent golden trace or test suite is supplied, and the repository appendix gives only a URL. This is a verification or evidence gap rather than circularity, because no equation or fitted parameter reduces the claimed result to an input of the same derivation. Accordingly no circular step can be exhibited, and the circularity score is 0.

Assumptions & free parameters 0 free parameters · 3 assumptions · 0 invented entities

FREESS introduces no fitted parameters or new physical entities. Its configurable widths and latencies are user inputs, not parameters fit to data. The central load-bearing assumptions are domain-level: Tomasulo's algorithm as reference model and the sufficiency of the modeled structures; the paper also assumes code correctness without providing verification.

assumptions (3)
  • domain assumption Tomasulo's algorithm, as introduced in [11], is the correct reference model for dynamic scheduling and is the standard taught in architecture courses.
    Section 1 relies on the algorithm and its structures (RM, FP, IW, ROB, LSQs) without re-deriving them.
  • domain assumption The structural components modeled by FREESS are sufficient to represent superscalar execution at an advanced-course level.
    Section 3 describes these structures as the complete state a student needs and explicitly narrows scope to course-level topics.
  • ad hoc to paper The C implementation is faithful to the described pipeline semantics.
    The paper asserts cycle-by-cycle states (Section 3.3) and gives only a repository address (Appendix A); no test suite or reference cross-check establishes this.

how reviews work

0 comments
Cite this review

Pith. "Pith review of FREESS: An Educational Simulator of a RISC-V-Inspired Superscalar Processor Based on Tomasulo's Algorithm." pith.science (2026). https://pith.science/paper/CW2MLMGP

@misc{pith2026250607665,
  author       = {Pith},
  title        = {Pith review of: FREESS: An Educational Simulator of a RISC-V-Inspired Superscalar Processor Based on Tomasulo's Algorithm},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/CW2MLMGP}},
  note         = {Machine review of arXiv:2506.07665}
}
read the original abstract

FREESS is a free, interactive simulator that illustrates instruction-level parallelism in a RISC-V-inspired superscalar processor. Based on an extended version of Tomasulo's algorithm, FREESS is intended as a hands-on educational tool for Advanced Computer Architecture courses. It enables students to explore dynamic, out-of-order instruction execution, emphasizing how instructions are issued as soon as their operands become available. The simulator models key microarchitectural components, including the Instruction Window (IW), Reorder Buffer (ROB), Register Map (RM), Free Pool (FP), and Load/Store Queues. FREESS allows users to dynamically configure runtime parameters, such as the superscalar issue width, functional unit types and latencies, and the sizes of architectural buffers and queues. To simplify learning, the simulator uses a minimal instruction set inspired by RISC-V (ADD, ADDI, BEQ, BNE, LW, MUL, SW), which is sufficient to demonstrate key pipeline stages: fetch, register renaming, out-of-order dispatch, execution, completion, commit, speculative branching, and memory access. FREESS includes three step-by-step, illustrated examples that visually demonstrate how multiple instructions can be issued and executed in parallel within a single cycle. Being open source, FREESS encourages students and educators to experiment freely by writing and analyzing their own instruction-level programs and superscalar architectures.

Figures

Figures reproduced from arXiv: 2506.07665 by the authors.

Figure 1
Figure 1. Structure of an Out-Of-Order Processor in FREESS. [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. Cycle-by-cycle simulation progress: the screen shows the state of the superscalar’s most relevant internal structures. [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗
Figure 3
Figure 3. At start, FREESS generates the text of an exercise with specific hypotheses on the architecture of the superscalar. For [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗
Figures from the paper (12 more)
Figure 5
Figure 5. Figure 5: In yellow, the most important simulator parameters [PITH_FULL_IMAGE:figures/full_fig_p003_5.png]
Figure 4
Figure 4. Figure 4: FREESS Parameters. FREESS PARAMETERS UNIT MEANING -fw number <inst/cycle> Number of instruction that can be fetched in a cycle -dw number <insts/cycle> Number of instruction that can be decoded in a cycle -iw number <insts/cycle> Number of instruction that can be issue…
Figure 7
Figure 7. Figure 7: Rename stage. The renamed instruction stream uses [PITH_FULL_IMAGE:figures/full_fig_p004_7.png]
Figure 6
Figure 6. Figure 6: Example-1. A simple loop that adds two vectors [PITH_FULL_IMAGE:figures/full_fig_p004_6.png]
Figure 8
Figure 8. Figure 8: The Instruction Window and ROB entries are allo [PITH_FULL_IMAGE:figures/full_fig_p005_8.png]
Figure 9
Figure 9. Figure 9: The third area of the screen (the accounting area) [PITH_FULL_IMAGE:figures/full_fig_p005_9.png]
Figure 10
Figure 10. Figure 10: Annotating issued instructions in IW and com [PITH_FULL_IMAGE:figures/full_fig_p005_10.png]
Figure 14
Figure 14. Figure 14: Example-2. Final output of the simulation of the [PITH_FULL_IMAGE:figures/full_fig_p006_14.png]
Figure 12
Figure 12. Figure 12: A command line that specifies: the name of the [PITH_FULL_IMAGE:figures/full_fig_p006_12.png]
Figure 15
Figure 15. Figure 15: Example-3. For the same program as in Example-2, [PITH_FULL_IMAGE:figures/full_fig_p006_15.png]
Figure 11
Figure 11. Figure 11: The final execution screen shows a summary of what happened during the program’s execution. In particular, the [PITH_FULL_IMAGE:figures/full_fig_p007_11.png]
Figure 16
Figure 16. Figure 16: The log file that lists all the stall reasons that [PITH_FULL_IMAGE:figures/full_fig_p007_16.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

12 extracted references · 10 canonical work pages

  1. [1]

    Castilla, L

    I. Castilla, L. Moreno, C. González, J. Sigut, and E. González. 2007. SIMDE: An Educational Simulator of ILP Architectures with Dynamic and Static Scheduling. Comp. App. in Eng. Education15, 4 (2007), 309–318. doi:10.1002/cae.20154

    doi:10.1002/cae.20154 2007

  2. [2]

    2012.Parallel Computer Organization and Design

    Michel Dubois, Murali Annavaram, and Per Stenström. 2012.Parallel Computer Organization and Design. Cambridge University Press, Cambridge

    work page 2012

  3. [3]

    Hennessy and David A

    John L. Hennessy and David A. Patterson. 2017.Computer Architecture, Sixth Edition: A Quantitative Approach(6th ed.). MKP Inc., San Francisco, CA, USA

    work page 2017

  4. [4]

    Hwu and Y

    W. Hwu and Y. N. Patt. 1986. HPSm, a high performance restricted data flow architecture having minimal functionality.SIGARCH Comput. Archit. News14, 2 (May 1986), 297–306. doi:10.1145/17356.17391

    work page arXiv 1986

  5. [5]

    J. Jaros. 2024. Web-Based Simulator of Superscalar RISC-V Processors. InICS’24. IEEE, Piscataway, NJ, USA, 1–6. doi:10.1109/SCW63240.2024.00209

    arXiv 2024

  6. [6]

    Mariotti and R

    G. Mariotti and R. Giorgi. 2022. WebRISC-V: A 32/64-bit RISC-V pipeline simula- tion tool.ELSEVIER SoftwareX18 (May 2022), 1–7. doi:10.1016/j.softx.2022.101105

    work page arXiv 2022

  7. [7]

    2004.Introduction to Computing Systems: From Bits and Gates to C and Beyond(2 ed.)

    Yale Patt and Sanjay Patel. 2004.Introduction to Computing Systems: From Bits and Gates to C and Beyond(2 ed.). McGraw-Hill, New York, NY, USA

    work page 2004

  8. [8]

    Petersen

    Morten B. Petersen. 2021. Ripes: A Visual Computer Architecture Simulator. In ISCA-WCAE’21. IEEE, Virtual Conference, 1–8

    work page 2021

Show all 12 references
  1. [9]

    C. W. Smullen. 2006. PSATSim: An Interactive Graphical Superscalar Architecture Simulator for Power and Performance Analysis. InISCA-WCAE’06. ACM, New York, NY, USA, 1–6. doi:10.1145/1275620.1275627

    2006

  2. [10]

    Thornton

    James E. Thornton. [n. d.].Design of a Computer: The Control Data 6600. Scott, Foresman and Co., Glenview, IL, USA

  3. [11]

    Tomasulo

    Robert M. Tomasulo. 1967. An Efficient Algorithm for Exploiting Multiple Arith- metic Units.IBM Journal of Research and Development11, 1 (1967), 25–33

    1967

  4. [12]

    S. Wolff. 2000. SATSim: A Superscalar Architecture Trace Simulator Using Interactive Visualization. InISCA-WCAE’00. ACM, New York, NY, USA, 1–7. doi:10.1145/1275240.1275249 A Online Resources The FREESS Educational Simulator for RISC-V inspired Superscalar Processors based on ...

    2000

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.