I guess my comment about 16 registers being enough was more in the context of low power. In benchmarks I've seen going from 8->16 is a big boost, but going from

I guess my comment about 16 registers being enough was more in the context of low power. In benchmarks I've seen going from 8->16 is a big boost, but going from 16->32 is generally only a few %. In ARM64 32 is definitely the right choice but in low power 16 is probably going to be best because with 32 your register file ends up taking up >50% of the die area and having 32 prevents you from fitting instructions into 16 bits (3 registers now uses 15 of your 16 bits, with 16 regs you have 4 bits leftover). On the register file split I think you're generally right, it just comes down to what the penalties actually look like from having the unified file. I think the loads are a cause of trouble, really you need two different types of loads rather than having a predictor I think (low-power implementations could ignore that single bit). It's really just a matter of those register file read ports, you are going to need a lot more or need less backends or get bottlenecked on read ports (remember not everything gets forwarded, much is already retired). One thing that's also relevant to the discussion is almost always when you add FP to a CPU these days you also add some kind of vector ops, and given vector registers are not the same length as the GPs you can't have a unified file. If I was doing green field I would probably go for a split file, but then say low power implementations shouldn't implement FP/vector at all (which is what RISC-V has done), unfortunately although this idea is popular with hardware designers it is not with software developers who are used to being able to drop a 'float' or 'double' into their C code and have it work (or worse may use a library that includes floats in its internals).