Maynard Handley (name99.delete@this.name99.org) on April 7, 2014 10:38 am wrote:
> Michael S (already5chosen.delete@this.yahoo.com) on April 7, 2014 2:20 am wrote:
> > Maynard Handley (name99.delete@this.name99.org) on April 6, 2014 3:52 pm wrote:
> > > 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.
> >
> > Writing status does not make sense, but it does not hurt. At least I don't see why it could possibly hurt.
> >
> > >
> > > 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.
> > >
> >
> > In theory that makes sense.
> > Trying to compare the theory with practice:
> > x87 has separate control and status words (=good), while SSE has them intermixed (=bad).
> > I tried to compare the speed of FNSTCW instruction (x87 Control Word read=good) vs STMCSR (SSE
> > Control/Status Word read=bad) in Agner's tables. Unfortunately, he provides very little information
> > about the latency of these instructions and even available information is unlikely to be reliable.
> > Which (lack of reliable information) sort of makes sense since the latency in this case is not
> > only hard to measure, it's even hard to define what exactly would be considered latency.
> > Agner has throughput number, so and for majority of cores the throughput of FNSTCW is, indeed,
> > significantly higher than STMCSR, but, first, in this case throughput is not very interested
> > and second, on Nehalem and SB/EB the thoughput is the same for both - 1 per clock.
> >
> >
> > > 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.)
> >
> > It's not clear to me where exactly you can do this "easy" attachment on OoO machine.
>
> At register rename time. In this model the control bits live in the FP register bank. Rename (which
> occurs in order) would read them from the bank for every FP instruction, just adding them to the
> instruction as a few more bits at the same time that rename info is being added to an instruction.
> Setting the control state would correspond to writing these bits in the FP register bank.
> This may require a one cycle hiccup at rename, something like setting FP control state is the only
> FP rename that can be processed during a single cycle, but that's much cheaper than what we have
> today, and will likely occur during function entry/exit where there's a cycle free anyway.
>
> This implementation means that my previous concerns about FP instructions sliding past the FP control write
> now become unimportant. After rename the FP control write is basically a NOP; we only need to keep tracking
> it in the case that we want to unwind after a mispredicted branch, so while we need to slot it into the
> ROB (probably carrying as freight the PREVIOUS value of the control bits), we can either never even put
> it in the dispatch queue, or we can drop it/send it to be (NOP) "executed" as soon as convenient.

So how do you know what value you need to attach to each FP instruction, given that the actual value of the control register write will be computed maybe 20 cycles after rename?

Wilco