3 ms·

Yes, the "dual register file" is probably the most intriguing to me. This looks like a renaming scheme used in some old micro-architecture (Intel Core 2 maybe)

Yes, the "dual register file" is probably the most intriguing to me. This looks like a renaming scheme used in some old micro-architecture (Intel Core 2 maybe) where ROB receives transient results and acts as a physical regfile, at commit reg value are copied to a arch regfile. But in your uarch the physical regfile is decoupled from ROB, which must correspond to your commitQ. I wonder if this solution is viable for a very large uarch (8 way) because read ports to copy reg value from pysical regfile to arch regfile are additional read ports that can be avoided with other (more complex) renaming scheme. These additional read ports can be expensive on a regfile that already has a bunch of ports. Any thoughts about this? But I haven't read much of your code yet, that's just a raw observation

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 ago
  I 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 ago
    I 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

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 ago
I 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 ago
  I 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