it's blowing up on RDTSC in l.s:/^cycles

cycles works only if m->havetsc is non-zero, and thus it's used in /sys/src/9/pc
with
	if(m->havetsc)
		cycles(...);
but now it's used in port (which is the call i think is failing)

../port/sysproc.c:	cycles((uvlong*)&tos->pcycles);

without the check.  could make port code check m->havetsc and require
all Mach to include that too, but i wonder whether it wouldn't be simpler to have
void (*cycles)(uvlong*) in pc/fns.h and have x86 processors that don't support it set
cycles to point to  a function zero the uvlong, and x86 processors that do support
it point to the existing code.  architectures where they manage to make their processors largely
the same can just define void cycles(uvlong*), and be done with it.
i'd have thought that zero'ing the vlong might be good anyway to avoid
calculating using rubbish on the stack when the processor doesn't support it.