The proposal uses URIUM, a simple programming language, to take a compiler-design course from language rules through analysis to generated assembly. Its compiler description covers MIPS32, MS-Windows on Intel64, Linux on AMD64, simulated RISC-V and Linux on a RISC-V board. The syllabus has 12 sessions and is presented as adaptable to a semester. The authors describe the result as a fully functional compiler built from scratch, but the paper gives no course delivery or learning assessment.
A deliberately narrow language
URIUM keeps its language definition deliberately compact. It specifies 17 reserved words and three data types, int, char and boolean, with 32-bit storage assumed for all three. Those are design choices in the specification, not measurements of storage use or performance.
To describe how programs are formed, the paper uses Backus-Naur Form, or BNF, a notation for writing grammar rules. The URIUM grammar contains 58 symbols and 108 rules. Its abstract syntax tree, the structured representation the compiler builds for a program, contains 26 classes distributed across four packages. These counts describe the implementation; the paper reports no parser-accuracy, runtime, memory or student-learning evaluation.
From analysis to machine-oriented output
The semantic analyzer handles meaning in two passes. A header pass collects procedure declarations, followed by a body pass that parses procedure statements. For syntax, the course selects JavaCC, a parser generator, and reports automatically generated versions of the header and body parser classes. The paper does not measure whether that automation reduces development effort or changes learning outcomes.
Between analysis and final code generation, the compiler uses a custom intermediate representation, a middle form used before the final output is produced. The paper calls its format three-address code, a way of representing a computation in explicit operations. It contains 24 instructions covering labels, arithmetic and logical operations, jumps, procedure calls and variable references. The paper reports no optimization or performance evaluation for this layer.
At output, compilation produces an assembly file with the .s extension. The default filename is Application.s, although the output name can be changed. The distribution also includes two native libraries, urium.Console and urium.Program, with corresponding assembly code for supported platforms. Native procedures are copied rather than generated.
Scope can change, evidence cannot
The multiple backends give the syllabus a way to change scope. The paper says the course can be adapted by reducing backend coverage and allocating more time to analysis lessons. That flexibility is proposed rather than evaluated through a teaching comparison.
That distinction sets the evidence boundary. The paper describes a language specification, compiler implementation, course syllabus, intermediate representation, native libraries and backend designs. It does not report a delivered course, student cohort or learning assessment, so it cannot show improved student learning, retention or course completion. Nor does it establish compiler speed, correctness rates, error rates, test coverage or portability benchmarks.
The authors present the work as an open course, with lecture content, source code and session instructions available through a repository and its wiki. That makes the materials available for inspection, but questions about classroom effectiveness and the reliability and portability of generated programs remain open.
Paper data and sources
Original title: URIUM: A Programming Language for a Practical Open Course on Compiler Design
Authors: Francisco J. Moreno Velo, Almudena García Jurado-Centurión
Journal/Repository: arXiv
Status: Preprint, not yet peer-reviewed
First online: 2026-08-28
DOI: Not available
Original paper · Full text