Immediate mystery solved.  I finally got the time to sit down with this
and just single-step and single-step, watching %g1.

It's the dynamic linker.  The first instruction of a dynamically-linked
called function, even after the dynamic linker has bound the call, is a
sethi to %g1.  (Even after the dynamic linker snaps the pointer, there
is still a tiny little stub trampoline the pc bounces through before
entering the real routine.)

Sure enough, linking -static made the symptom go away.

I'm not sure where this fits into the ABI/API spec; for example, is the
dynamic linker considered application code?  Or is it just all my own
fault for calling an internal routine (.mul) without being aware that a
critical part of its interface spec is "when dynamically linked,
clobbers %g1"?

I may end up copying the multiply code from mul.S into my program; that
way there will be *no* code involved that isn't right there.  Or I may
take advantage of a little application-specific knowledge to optimize
the multiply even further (one of the arguments can take on only
somewhat under 2K possible values; it's an 8-bit number shifted left by
a 3-bit number - and that value changes seldom, compared to how often
multiplies occur).  Doing this would even free up a couple of the %o
registers that I now feel I have to let .mul have for its own use....

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B