The C codes generated by Usubac are compiled to assembly using C compilers. While in C, a (virtually) unlimited amount of variables can be used, Assembly can only use a few registers (between 8 and 32 for commonly used CPUs). C variables are thus mapped to assembly registers using a _register allocation_ algorithms. When too many registers would be required, registers are spilled, and the stack is used to temporary store some variables. Read More...
Cryptol started from the observation that due to the lack of standard for specifying cryptographic algorithms, papers described their ciphers using a combination of english (too ambiguous) and pseudo-codes (ill-suited to describe mathematical operations) while providing reference implementations in C (too low-level) Read More...
General purpose processing on graphics processing units (GPGPU) has gained a huge interest within past decades. GPGPU relies on CPU deciding to delegate heavy arithmetic and parallel work to one or several GPUs. GPGPU is a solution to the scalability of those issues and having already a GPU among nearly all servers and laptops avoids creating and introducing new specific and costly hardware component for this purpose. Read More...
A first optimization in Usubac consists in interleaving several executions of the program. For a cipher using a small number of registers (for example, strictly below 8 general-purpose registers on Intel), we can increase its instruction-level parallelism (ILP) by interleaving several copies of a single cipher, each manipulating its own independent set of variables. Read More...
Usuba's compiler, Usubac, consists of two phases. The front-end distills Usuba's high-level constructs into a minimal core language, while the back-end performs optimizations over the core language. The core language, called Usuba0, amounts to dataflow graphs of Boolean and arithmetic operators. In its final pass, the back-end translate Usuba0 to C code with intrinsics. Read More...