4 ms·
the commitQ entries are smart enough to 'see' the commits into the architectural file and request the data from it's current location It does mean lots of regi
by Taniwha 5y ago
the commitQ entries are smart enough to 'see' the commits into the architectural file and request the data from it's current location
It does mean lots of register read ports .... but you can duplicate register files at some point (reducing read ports but keeping the write ports) (you want to keep them close to the ALUs/multipliers/etc) - in some ways these are more implementation issues rather than 'architectural'
- avianes 5y agoI see, there are indeed solutions like regfile duplication to handle large port number but it's expensive when physical regfile becomes large. I still think that the uarch's job is to ensure minimal implementation cost ;). Thank you for your opinion and thought process, it's very valuable !
- Taniwha 5y agoI think that one has to separate out architecture and implementation a bit, they're obviously a deeply intertwingled dance - but you have to start with the architecture and tweak from there to get the best result in the end - I'm probably halfway through that process now, starting to introduce deeper timing constraints to flesh out that stuff BTW once great thing that sort of falls out of this architecture is that the commit register file gets shared between the integer and FP registers (and probably vector registers too), and duping just that may be an interesting architectural way to go