Re:The MRISC32 – A vector first CPU design
by monocasa on Friday August 24, 2018 @07:20PM
(#17838541)
They still keep the physical register files split between integer and floating/vector, despite the renaming that happens on each of the pipes. Ironically enough the integer file has more physical registers than the vector file on most uarchs (although less bits).
[ Parent
| on HN ]
Re:The MRISC32 – A vector first CPU design
by _chris_ on Friday August 24, 2018 @08:49PM
(#17838929)
If your processor uses register renaming, the frequency of your core limits how many physical registers you can have in the register file. Therefore, you are incentivized to split integer and floating point register files so you can size up each register file to its limit.
You can also play other games like internal recoding the FP format if you split the register files.
On the other hand, you can remove the need for IntToFP and FPToInt move instructions if you use one register file.
At the end of the day though, I suspect it largely comes down to having more addressable architectural state to keep the two register files separate. Why have only 32 scalar registers when you can have 32 scalar int and 32 scalar fp registers?
Re:The MRISC32 – A vector first CPU design
by mbitsnbites on Saturday August 25, 2018 @04:36AM
(#17840123)
I suspect that what you say is true. One thing worth considering though is that on x86_64 you actually use the vector register file for floating point (and it can do integer too!).
On the MRISC32 you have a vector register file with 32 registers that can easily be configured to do scalar operations (integer or floating point) by setting the vector length to 1.