Comparison of instruction sets

ForwardCom is a proposal for an open instruction set and associated software standards. Below is a schematic comparison of ForwardCom with a few other open and proprietary instruction sets. This list is intended to highlight where ForwardCom differs from other instruction sets. It is not intended to be a complete overview of instruction sets.

Intellectual rights
Basic Technology
Level of standardization
Development status
Instruction size
Immediate constants
Vector support
Forward compatibility with future extensions of vector length
Flags, branches and conditions
Built-in security features
Memory management
Function calling conventions
Function library types
Assembly language
Summary

Intellectual rights
ForwardCom	Manual: Creative Commons license. Binary tools: Gnu Public License. Soft core: CERN open hardware license
RISC-V	BSD license
Open RISC	Gnu Public License
x86	Protected by patents
ARM	Protected by patents

Basic technology
ForwardCom	Neither RISC nor CISC, but a new paradigm combining the fast decoding and streamlined pipeline of RISC with the more work done per instruction of CISC. There are few instructions but many different variants of each instruction, defined by a consistent template pattern.
RISC-V	RISC
Open RISC	RISC
x86	CISC
ARM	RISC

Level of standardization
ForwardCom	The ForwardCom project aims at standardizing not only the instruction set, but also the application binary interface (ABI), file formats, function calling convention, and to some degree system functions. It will be possible to use the same function libraries, linkers, debuggers, etc. with different programming languages and in different operating systems. It will be possible to link together pieces of code written in different programming languages. It should even be possible to use the same binary program code on different platforms by relinking with different user interface libraries.
RISC-V	Function calling convention is standardized.
Open RISC	Most of the ABI is standardized.
x86	No binary compatibility between platforms. Different compilers are historically incompatible, even on the same platform. Windows: Incomplete ABI documentation by Microsoft. Linux, BSD, MacOS: A long history of draft ABI specifications (System V ABI) published in various obscure places, but no official final version.
ARM	Most of the ABI is standardized.

Development status
ForwardCom	A long phase of discussion and experimentation is needed before details are fixed because of the ambition of a complete vertical redesign of both hardware and software standards. Most details are in place but changes are still possible. All application-level instructions and some system functions are defined. Software standards and file formats are defined. Software tools are available. An FPGA soft core for integer instructions is available.
RISC-V	Instruction set defined. Software standards partially defined. FPGA implementations available. ASIC chip available.
Open RISC	Instruction set defined. Software standards defined. FPGA implementations available. No ASIC implementation.
x86	Fully developed and implemented. Continuously developed.
ARM	Fully developed and implemented. Continuously developed.

Instruction size
ForwardCom	1, 2, and 3 words of 32 bits each.
RISC-V	32 bits. Possibility for any multiple of 16 bits.
Open RISC	32 bits.
x86	All sizes from 1 to 15 bytes. The detection of instruction size is complicated and often a bottleneck.
ARM	32 bits (16 bits for Thumb instruction set).

Immediate constants
ForwardCom	Integer and floating point constants can be embedded in instructions to reduce data cache load. Constants are stored in the smallest form that fits the actual value: Sign-extended integers of 8, 16, 32, and 64 bits. Shifted integers. Floating point constants of half, single, and double precision. Relative jump and call addresses of 8, 16, 24, and 32 bits. Relative memory addresses of 8, 16, and 32 bits. Constants have natural alignment.
RISC-V	Constants do not have power-of-two sizes. Some constants are non-contiguous.
Open RISC	16 bit constants and 16 bit relative addresses. Some constants are non-contiguous. Relative jump and call addresses of 26 bits.
x86	Sign-extended integers of 8, 16, 32, and 64 bits. Relative jump and call addresses of 8 and 32 bits.
ARM	Constants do not have power-of-two sizes.

Vector support
ForwardCom	Variable-length vectors. The maximum vector length is implementation-dependent with no upper limit. An array loop can automatically use the maximum available vector length. No need for extra code to take care of the remaining elements if the array length is not divisible by the vector length. No need to compile the code separately for different vector lengths. The same binary code will run optimally on different processors with different maximum vector lengths. It is always possible to save and restore a full vector, or the part of it that is used, even if the actual vector length was not available when the code was compiled.
RISC-V	Under development. Maximum vector length is implementation-dependent.
Open RISC	Limited to 64 bits.
x86	64, 128, 256, and 512 bit vector registers. Each new vector length has involved a new and radically different instruction set extension.
ARM	128 bit vectors. The Scalable Vector Extensions (SVE) allows vectors of 128-2048 bits in 128 bit increments.

Forward compatibility with future extensions of vector length
ForwardCom	Yes. An efficient loop structure automatically uses the maximum vector length in all but the last iteration of a loop. The last iteration uses a vector length that matches the remaining number of elements.
RISC-V	No
Open RISC	No
x86	No
ARM	The so-called vector length agnostic programming under the Scalable Vector Extensions (SVE2) will allow software to adjust to the available vector length at run-time.

Flags, branches and conditions
ForwardCom	No flags register. Branching uses combined ALU-and-branch instructions or a special multiway branch instruction with a table of relative addresses. Instructions can be predicated. Vector instructions can be masked.
RISC-V	Combined compare-and-branch instructions.
Open RISC	A 1-bit flag is set by compare instructions. Branch instruction is conditional upon flag.
x86	Various bits in a flags register are set by most integer ALU instructions. Conditional jumps depend on flag bits. Vector instructions can be masked.
ARM	ALU instructions optionally modify a flags register. Instructions can be conditional upon the flags, including jump and call instructions.

Built-in security features
ForwardCom	Many
RISC-V	No
Open RISC	No
x86	Few
ARM	Optional

Memory management
ForwardCom	On-chip memory map with a small number of variable-size memory blocks. No fixed-size pages. Various features to minimize memory fragmentation. All code is position-independent.
RISC-V	Translation look-aside buffer (TLB) and page tables.
Open RISC	Translation look-aside buffer (TLB) and page tables.
x86	Translation look-aside buffer (TLB) and page tables with up to five levels.
ARM	Translation look-aside buffer (TLB) and page tables with up to three levels.

Function calling conventions
ForwardCom	Separate call stack and data stack. The return address is on the call stack. The call stack resides in the CPU and rarely spills to memory. Parameters are transferred in registers, or use a list if out of registers. No parameters on stack. Some g.p. registers and some vector registers have callee-save status. Linker support for optimizing register allocation across modules. Stack size is calculated by compiler and linker to prevent stack overflow.
RISC-V	Return address in general purpose register. Parameters in registers or stack. Some g.p. registers and some f.p. registers have callee-save status.
Open RISC	Return address in link register. Parameters in registers or stack. Some g.p. registers have callee-save status.
x86	Return address on stack. 32 bit mode: parameters on stack. 64 bit mode: parameters in registers or stack. Not standardized across platforms. Some g.p. registers have callee-save status. Some vector registers have callee-save status for part of the register in 64-bit Windows, but not in other systems.
ARM	Return address in link register. Parameters in registers or stack. Some g.p. registers and some f.p. registers have callee-save status.

Function library types
ForwardCom	Only one type of function libraries, used for both static linking, relinking, load-time linking, and run-time linking. Provides efficient caching of code and data and avoids memory fragmentation. Unused functions are not loaded. Multiple copies of the same function may be loaded if used by multiple applications. Register use and stack use for each function is specified in object files. Different versions of a function library may be selected during installation, depending on operating system, user interface framework, hardware configuration, etc.
Windows	Static libraries (.lib) and dynamic link libraries (.dll). Poor caching. Wasteful use of memory pages.
Linux, BSD, MacOS, etc.	Static libraries (.a) and shared objects (.so). Poor caching. Wasteful use of memory pages. The rarely used symbol interposition support makes the code inefficient. Inefficient position-independent code in 32-bit x86.

Assembly instruction syntax
ForwardCom	Syntax is similar to high-level language (see details).
RISC-V	instruction, register operand, memory operand.
Open RISC	instruction, destination operand, source operand.
x86	Many different versions in use with different orders of operands.
ARM	instruction, register operand, memory operand.

Summary of the unique features of ForwardCom

A complete vertical redesign enables us to learn from past mistakes and make an optimal design through an open collaborative process.
Combines the best from RISC and CISC. Few instructions with many variants of each instruction.
Software will be forward compatible with future extensions of vector length without recompilation.
Variable vector length. Vector loop structure with no remaining elements after loop and no additional overhead costs.
Mechanism for saving and restoring only the part of a vector register that is used.
Fully orthogonal instruction set: The same instruction can have 2- or 3-operand forms, different register types, scalars or vectors, integer operands of different sizes, floating point operands of different precisions, immediate operands of different sizes, and memory operands with different addressing modes. Immediate operands can have full size or a smaller size when compression is possible.
All instructions fit into a consistent template system. This makes decoder and pipeline simpler.
Instructions can have a few different sizes. The code is made compact by using the smallest possible instruction size, while the detection of instruction size is very simple.
A single instruction can do multiple things such as calculating a data address, reading data from this address, and do a calculation with this data. But this has to fit into a certain pipeline structure with one thing at each pipeline stage. Complexity that does not fit into the pipeline design is avoided. No complex micro-coded instructions.
Designed for a consistent hardware pipeline structure that facilitates a superscalar design.
All code is position-independent. Virtual address translation is not needed in simple cases.
No memory paging, but a memory map with variable-size memory blocks. Several methods are used for avoiding or minimizing memory fragmentation.
Child threads have private memory by default.
No dynamic link libraries, but a more efficient universal library format that can be linked or relinked at build time, installation time, load time, or run time.
Separate call stack and data stack. The call stack resides inside the CPU most of the time. An efficient function calling convention avoids parameters on the stack.
The stack size is calculated by the compiler and linker to prevent stack overflow.
Global register allocation is optimized by storing information about register use in object files.
Suitable for efficient superscalar and out-of-order processor design: Each instruction has only one output. No shared flags or status registers. No partial register writes. No numerical exception traps. No interdependence between data stack and call stack.
No flags register, but predication, masks, combined ALU-branch instructions, multiway branch instruction, and multiway call instruction.
Floating point errors are traced using NAN payloads rather than traps (see details).
Options for detecting signed and unsigned integer overflow.
Binary compatibility between different compilers, programming languages, hardware platforms, operating systems, and user interface frameworks obtained by standardization of file formats, ABI, error message system, and other software details.
Assembly language syntax intelligible to high-level language programmers.
Strong security features built into the design.
Device drivers and system modules have carefully controlled access rights. They can access only a specified memory block of the calling application.
Protection against malware by a standardized program installation procedure and defined access rights for program files.

Comparison of instruction sets

Contents:

Summary of the unique features of ForwardCom