> > As far as I can recall, there was nothing about flushing write buffers in the
> > doc. I had for the 3min and maxine. 
> 
> The NetBSD pmax code uses one branch condition input to check if the
> write buffer have drained.  This was the ususal/recomended way if one
> used the Mips four level write buffers chips. These chips tried to
> optimize reads so that read accesses to addresses stored in write buf
> was stalled until they was written out. Read accesses to addresses not
> present in the write buffer could then be prioritized and contribute to
> a little better performance. However for writes to I/O's writing to a reg
> does not necessary mean that you read the same address again but one next
> to it. To achive right order one could connect the 'empty' pin on the write
> buffers to one of the BCn inputs on the processor and the just loop until
> the buffer was empty.

Bizzare. I'm surprised MIPS didn't put a specific flush mechanism into
the processor (a pipeline stall is cheaper than a loop checking for
completion.)

> How it is done in other DEC systems is more than i know but my guess is
> that they use a similar solution.

If it is done differently on different models, it probably calls for a
function indirection to per-processor wbflush routines.

> Derivates, IDT3081 for instance, uses other methods. It just stalls until
> the write has been done.

Yeah. The book I have says that IDT processors work in the following
way: If a read is done from an uncached address, the processor stalls
until the write buffer has flushed. (Apparently to make flushing easy,
and so that they didn't need write-then-read collision detection
circuitry.)