> 1) an MI interface to a high speed counter/timer, such as, say, a
>    macro to access a CPU instruction counter if one exists. If there
>    isn't such a low cost/high resolution timer available, microtime
>    could be used (but its best to avoid that if a better timer is
>    available.)

What I recommend is a very small MD stub function with an MI interface
of zero or one parameters which:

	- samples the timer
	- stuffs the timer value (and a "channel number" if one is provided)
	  into a buffer if there's room
	- returns to the caller or tail-calls the real interrupt
          service routine.

The buffer can then be digested using purely MI code from a timer
callout or (better yet) in a low-priority software interrupt posted by
a timer callout..

If stores of pointers are atomic, this can run completely lockless as
long as the buffer never moves or changes size; you will lose samples
collected while the buffer is being reduced, but this is a relatively
minor problem.

The stub function can either be called explicitly from certain device
drivers, or else it can be spliced into the interrupt path for all
devices.  

The hook function is literally only 10 instructions on the hp700:

randomhook
	MFCTL	%cr16, t1			 ; cycle counter
        ADDIL   LR'randomhookbase-$global$,%dp,%r1	 ; common base..
        LDW     RR'randomhookbase-$global$+rhvec(%r1),t4  ; "real" vec ptr
        LDW     RR'randomhookbase-$global$+rhbase(%r1),t2   ; current ptr
        LDW     RR'randomhookbase-$global$+rhend(%r1),t3    ; end ptr
	LDWX,S	%arg0(t4), t4			 ; "real" interrupt vector
        COMCLR,>>=      t2,t3,%r0		 ; room in buffer??
        STWS,MA  t1,4(t2)			 ; [>>=] yup, save it..
	BE	0(t4)				 ; and tail-call "real" handler
        STW     t2,RR'randomhookbase-$global$+rhbase(%r1)  ; [DELAY] and the ptr, too.

On other systems, your mileage may vary :-)

						- Bill