For reasons that don't bear repeating, I recently found myself looking
through bus.h and pio.h in netbsd-macppc, and was somewhat surprised by what
I saw.

I've never done much kernel hacking, but I _have_ worked on commercial
drivers and graphic acceleration for a couple of different video cards under
MacOS, and I thought I had a pretty good grasp of bus access reordering on
the PowerPC.  In code that I've written, I've always been careful to use
barrier instructions (eieio, isync and sync) only when it was really
necessary.  IIRC, sync is particularly bad for performance.

Indeed, according to the instruction description for 'sync' in "PowerPC(tm)
Microprocessor Family: The Programming Environments for 32-bit
Microprocessors":

"The functions performed by the sync instruction will normally take a
significant amount of time to complete, so indiscriminate use of this
instruction may adversely affect performance.  In addition, the time
required to execute sync may vary from one execution to another."

The thing which surprises me is that bus_space_barrier() is defined as a
no-op, and the various bus_space_read*() and bus_space_write*() functions
all call through to functions in pio.h which end with:

__asm__ volatile("eieio; sync");

Aside from the fact that sync AFAIK performs a strict superset of the
operations performed by eieio, this seems like it violates the spirit of
what bus_space_barrier() is intended for.

Am I missing something basic here, or are the MI drivers in the various
macppc ports being dreadfully inefficient?

-- monroe
------------------------------------------------------------------------
Monroe Williams                                  monroe@criticalpath.com