[Please read the attached PDF file on my Alternative RV128 if you need further background information to my discussion below] *Below, I'm going to challenge an assumption in "Original" RV128 that all 32 integer registers should be the same (128b) size*. I instead propose the Alternative RV128 register file consist of 16x 64b plus 16x 128b as follows: [image: Alternative RV128 Register File.png] *The above naming of the registers is for what I call the X64 ABI. This is intended to be a 10 year transitional ABI - until 128 bit pointers are needed (note addresses in current hardware maxes out at 57b). Note in X64 ABI, the pointers are plain 64b, there is no segmentation, no tricks to get anything more than 64b. My attached PDF has details on the next stage 128ABI,, and discusses design choices to allow greater interoperability between X64 ABI and 128 ABI. Also, please note that transition from X64 ABI to 128 ABI is a software only transition - the whole point of X64 is to get the 128b hardware installed & bedded down, so that software-only transition to 128b pointers can then be done in a highly granular way over 10+yrs.* *My motivation is the fact that 128b registers are more energy hungry than 64b registers:* 128b registers should be exposed as a separate size class in the ISA, as this is something we actually want to make **harder** for compiler writers. We don't want them assuming <=64b quantities can just be shoved into 128b registers indiscriminantly. The CPU shouldn't be abstracting away the fundamental energy consumption difference between large (128b) & small (64b) registers. We want compilers to make thoughtful choices about handling of large data sizes vs small sizes, to produce more energy efficient code. Note: in Alternative RV128, I've retained separate 5b register fields are used for each source & the destination, to select from the 16x64b + 16x128b registers. So integer operations can still effortlessly mix and match any combination of 64b and 128b source operands (once they've allocated registers appropriately). *Of course, the obvious disadvantage of my proposal is that the number of 128b registers is now reduced to only 16 (the other 16 registers being only 64b)*: (i) Firstly, this disadvantage is a matter of choice of benchmark, such as compared to "Original" RV128 (which has 32x 128b registers). Compared to x86_64, the total number of registers (of any size class) in my proposal has actually increased from 16 to 32 and likewise my proposed Alternative RV128 is superior to RV64 & ARM64 in it's register file capacity & "future-proofing". I believe the latter three comparisons are more appropriate, as I anticipate the target market for 128b computing is to upgrade existing Legacy 64b systems, and RV64/ARM64 will be compared as alternative options in this upgrade process. (ii) Secondly there are diminishing returns in increasing the register file beyond 16 registers (of any size), and many programs do not use more than 16 registers. (iii) Thirdly, even amongst programs using all 32 registers, a substantial fraction of registers will be for 8b/16b/32b/64b data. Many scalar magnitudes in the "real world" are less than 2^32, for which an Int32 is sufficient & pointer sizes/array indices will remain 64b or less for many years (we don't even use all 64b of x86_64 virtual address space). It is likely for the foreseeable future that most programs will use a range of integer sizes, and universal 128b integers for everything will *not* to happen. *Apart from energy consumption, the other reasons for having dual (64b & 128b) size classes of registers are:* *a. Compactness & orthogonality of 64/128 size class encoding*. In Alternative RV128, the size class is the MSB of every 5 bit src/dest register field, so any instruction referencing one or more registers automatically supports 64b and 128b operations, including for mixed data size operations. In comparison, RV64 has a triplicate system for encoding operation size, with different function codes used to represent data sizes in LOAD, STORE and OP/OP-32. Original RV128 adds a further OP-64 and a new encoding for LQ. Furthermore, RV64 only has one size class for branch instructions, so all branches must do a 64b compare, even if they are comparing against zero or one. This can waste up to 63 bits, but in "Original" RV128, the problem is even worse, with branches only able to do 128b compares, and so up to 127 bits are wasted. In Alternative RV128, because branches encode two source registers, any combination of 64b & 128b comparison/branch is automatically & consistently supported. I admit though that the 32b size isn't dealt with so nicely as there is no separate 32b register size class. But this size class is less important than the 64b size class - as a 64b register will only waste 32b (when holding a 32b quantity), whereas a 128b register wastes 64b (holding a 64b quantity). *b. Existing x86_64 ABIs (which assume 16x 64b registers) can be transplanted* onto Alternative RV128 easily. Legacy 64b code (eg. a processor with an x86_64 mode switch) can make function calls to new X64 ABI code, and vice versa, new X64 ABI code can call Legacy 64b code. Please also see the attached PDF for further thoughts & design choices on how to allow Legacy 64b (x86_64) code to interoperate with 128 ABI code. *c. Reduced transistor budget for the register file*. Alternative RV128's mixed 64b/128b register file is only 50% more transistors than RV64 (not 100% more like Original RV128). This is quite a modest transistor budget for a much more future-proof, wider register set. This one of the reasons why I assert the case that RV64 should be bypassed entirely by Legacy 64b systems, which should instead upgrade directly to Alternative RV128.