Hacker News new | past | comments | ask | show | jobs | submit login

Yes. My question wasn't if processors have split register files. The question was why the split is exposed at the instruction level instead of being hidden away as an implementation detail. Register renaming hardware is very common in modern processor designs and would make it very easy to make split physical register files look like a unified architectural register file.

I did a bit more reading, and both the IBM Cell and the Adepteva Epiphany processors expose unified register sets at the instruction level (architectural registers).

Many processors these days already contain the hardware to hide this away as an implementation detail, giving more design flexibility to the hardware designers. Furthermore, the processors that don't have register renaming hardware are likely to be small embedded processors that would benefit from not having split register files.




By exposing it at the ISA level you save bits in every instruction through having the register addressing implicit in the instruction type.


That's only true if you replace, say, 32 integer and 32 fp registers with 64 registers. As I mentioned, very few functions require both a large number of fp and a large number of integer registers.


You were talking about high end processors with register renaming though, right? At that point you have stuff like L2 caches which take up way more transistors than the register file. And with one register file the space near it is going to be at a premium as you try to squeeze both the integer and floating point execution units near to it. But with separate clusters you can surround your integer register file with the integer bypass network and the integer execution resources and you can surround your floating point execution unit with your floating point execution units and bypass network. It's the same reason, mostly, that processors have split data/instruction L1 caches - you want to put the cache near the structures that use it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: