Article: AMD's Jaguar Microarchitecture
By: Maynard Handley (name99.delete@this.name99.org), April 6, 2014 3:52 pm
Room: Moderated Discussions
Michael S (already5chosen.delete@this.yahoo.com) on April 6, 2014 1:50 am wrote:
> Maynard Handley (name99.delete@this.name99.org) on April 5, 2014 6:01 pm wrote:
> > Michael S (already5chosen.delete@this.yahoo.com) on April 5, 2014 10:59 am wrote:
> > >
> > > I don't follow.
> > > Why should one save/restore the whole FPU state, why not only FP control register? Saving/restoring
> > > only FPU control register is not slow relatively to the rest of library call overhead
> > > and it *should* be done by any library that wants to use non-default control bits. Anything
> > > less is bug and should not be tolerated bu library users.
> > >
> >
> > By FPU state I mean the stuff that would be in an FP control register. I don't
> > mean the state of standard FP registers. Sorry, I guess that was not clear.
> >
> > The point is
> > (a) put it ALL CONTROL state in ONE register. And don't make the problem artificially
> > more complicated by mixing up CONTROL bits with STATUS bits.
> > (b) allow rapid reading and writing of that control state register with a single user level
> > read/write operation, instead of a twiddle one bit at a time with high latency model.
>
> Intel/AMD MXCSR, indeed combines control and status in the same registers. Same for Power FPSCR. And, indeed,
> I don't like it from pure theoretical point of view. But in practice it is not a significant problem.
Reading and writing control both make sense, writing status does not make sense.
Reading control can be as fast as reading any other register, reading status means you have to delay the read until the status is available.
Writing control (in a model where control is separate from status) is also easy and fast because now "all" you do is attach the control bits (as they are defined at the point of instruction execution) to each instruction, and they then flow along with instruction execution. At the point where you're making each decision (rounding, deform, etc), you consult the attached bit, not the global register. The main additional feature you need to add is that FP instructions later than a change of FP control don't move past an FP control write. (Or you can speculate on this, but an explicit test is probably easier and more performant.)
PPC allows for 4-bit at a time twiddling of the FPSCR. This has the potential to be faster than reading and writing the whole thing because now you aren't necessarily delayed by the status bits; but it does mean that pulling out/shoving in the data you want is now two instructions (I think there are 8 control bits of interest on PPC, but it's been a while) each time, instead of one, and two registers that have to just sit around storing that info otherwise unusable, or which have to be pushed then popped.
> Maynard Handley (name99.delete@this.name99.org) on April 5, 2014 6:01 pm wrote:
> > Michael S (already5chosen.delete@this.yahoo.com) on April 5, 2014 10:59 am wrote:
> > >
> > > I don't follow.
> > > Why should one save/restore the whole FPU state, why not only FP control register? Saving/restoring
> > > only FPU control register is not slow relatively to the rest of library call overhead
> > > and it *should* be done by any library that wants to use non-default control bits. Anything
> > > less is bug and should not be tolerated bu library users.
> > >
> >
> > By FPU state I mean the stuff that would be in an FP control register. I don't
> > mean the state of standard FP registers. Sorry, I guess that was not clear.
> >
> > The point is
> > (a) put it ALL CONTROL state in ONE register. And don't make the problem artificially
> > more complicated by mixing up CONTROL bits with STATUS bits.
> > (b) allow rapid reading and writing of that control state register with a single user level
> > read/write operation, instead of a twiddle one bit at a time with high latency model.
>
> Intel/AMD MXCSR, indeed combines control and status in the same registers. Same for Power FPSCR. And, indeed,
> I don't like it from pure theoretical point of view. But in practice it is not a significant problem.
Reading and writing control both make sense, writing status does not make sense.
Reading control can be as fast as reading any other register, reading status means you have to delay the read until the status is available.
Writing control (in a model where control is separate from status) is also easy and fast because now "all" you do is attach the control bits (as they are defined at the point of instruction execution) to each instruction, and they then flow along with instruction execution. At the point where you're making each decision (rounding, deform, etc), you consult the attached bit, not the global register. The main additional feature you need to add is that FP instructions later than a change of FP control don't move past an FP control write. (Or you can speculate on this, but an explicit test is probably easier and more performant.)
PPC allows for 4-bit at a time twiddling of the FPSCR. This has the potential to be faster than reading and writing the whole thing because now you aren't necessarily delayed by the status bits; but it does mean that pulling out/shoving in the data you want is now two instructions (I think there are 8 control bits of interest on PPC, but it's been a while) each time, instead of one, and two registers that have to just sit around storing that info otherwise unusable, or which have to be pushed then popped.