On Thu, Apr 30, 2009 at 2:54 PM, Korey Sewell <ksew...@umich.edu> wrote:
> > Actually it does because -all- floating point registers are then 32 bits. > > The existence of 64 bit registers is just an illusion the instructions > > provide by gluing two 32 bit registers together internally. > I understand that for MIPS/SPARC, but does the same hold true for Alpha? > > I'm encountering an issue where the instruction is "divt f1,f0,f0" > > From looking at the generated output, alpha is expected both f1 and f0 > to be double precision registers. > > Whereas, in say MIPS/SPARC, when you say f0, you really mean f0+f1. > > Or am I just misinterpreting how alpha is working? Guess I need to > double check, but I thought the above holds... > In MIPS/SPARC, the individual FP regs are 32 bits (single precision), and you use two of them together to store a 64-bit (double precision) value. In Alpha, the individual regs are 64 bits, and if you only store a single precision value in one, then you just waste half the bits. IMO, the MIPS/SPARC idea is a point solution that makes sense for certain implementations (where you can explicitly design the FP reg file to support accessing adjacent pairs of 32-bit registers as a 64-bit value) that were likely at the time they were designed, but adds awkward artifacts if you consider an out-of-order implementation with dynamic dependence tracking (which they apparently didn't). In contrast, Alpha went for the clean solution even though it arguably is a little wasteful; by the time Alpha was designed, transistors were plentiful enough that the waste was not as big an issue as the design complexity. You can see this same effect with regard to branch delay slots as well (cute optimization for a 5-stage pipe, but ugly in OOO; MIPS/SPARC have them, Alpha doesn't). Anyway, to address Korey's specific issue #2 in his previous email: at what point does the CPU model care whether it's doing a 32-bit or a 64-bit access to the FP reg file? As long as it gets the scheduling dependencies right and execute() gets the right answer, I'd say the timing model shouldn't know the difference. The one case where it might matter is if you were doing a power model, but for now that's not an issue for us. Steve
_______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
