Architecture
This category explains the architectural decisions made while designing Onigiri256. It is inherently a hybrid between a RISC (Reduced Instruction Set Computer) and a CISC (Complex Instruction Set Computer) architecture; it entirely depends on the area where you’re looking. In arithmetics, it leans closer to a CISC, while in other areas, it leans closer to a RISC architecture.
In code contexts, Onigiri256 will be referred to as onigiri256.
|
Opcodes
Onigiri256 handles fixed-size 32-bit opcodes represented in hexadecimal. For example, 0x00000001 for switching into User Mode.
| Opcodes are going to be unpadded in the rest of the documentation for readability. |
Operational Modes
Onigiri256 comes with two modes: bootmd (Boot Mode) and usermd (User Mode). Boot Mode provides a restricted instruction set (e.g., SIMD is stripped out), while User Mode provides a full instruction set.
Switching into Boot Mode requires the 0x0 opcode and guarantees that the first 4,096 bytes (4 KiBs) all consist of zeroed bits. While switching into User Mode requires the 0x1 opcode and it does not make any guarantees about zeroed memory [1].
See the Onigiri256 ISA (Instruction Set Architecture) Documentation for more information.
Onigiri Shared Memory
OSM is RAM shared between the SoC’s CPU and GPU for zero-copy graphics and compute operations.
Memory addresses in OSMRAMX1 are byte-addressed (this might change in future generations), as to stop values below 256-bits, for example, single byte values, from taking up more space than they need, thus reducing total usable capacity. Little-endian ordering is being used in OSM (values decrease with the next memory address).
OSM is truly shared memory. Both the CPU and GPU can access the same memory address at the same time (not in the same CPU cycle). Race conditions are up to the software running on top to handle. This also means the GPU also handles 256-bit memory addresses.
Floating Point Numbers
Floating point numbers are, uniquely, represented rationally on Onigiri256. It is quite inaccurate to call them floating-point numbers at this point, since they’re derived from ORF256 (Onigiri Rational Format).
For example, a 256-bit floating point number is represented as a 128-bit number over a 128-bit number (\(\frac{\text{128-bits}}{\text{128-bits}}\)). This is to fix the issues of precision in IEEE 754. A hardware-level GCD (Greatest Common Divisor) calculator is used to prevent overgrowing numbers (e.g., \(\frac{3}{9}\) will be converted to \(\frac{1}{3}\)). The \(\frac{\text{bits}}{\text{bits}}\) formula scales exponentially with the float’s word size.
Extendable Design
Onigiri256 is meant to be extended by ISA Extensions. The 0x3 opcode reports the available extensions on the CPU. See the Onigiri256 ISA Documentation for a complete set of ISA Extensions.
One example of an ISA Extension is OPE1024 (Onigiri Parallel Execution), which provides SIMD (Single Instruction, Multiple Data) for 1024-bit wide operations (e.g., \(16*\text{64-bits}\), \(8*\text{128-bits}\), \(4*\text{256-bits}\), etc.).