Yes, the value is per (kernel-) thread. If you look at pseudo-code
for the swpctx PALcall, you'll see that the unique value gets stored
in the "process" control block. In Linux, the corresponding variable
is the "unique" member in processor.h:struct thread_struct.
> How are they used in DEC Unix?
Don't know. I don't think the architecture manual says so explicitly,
but the intent seems to be that the kernel does not interpret the
unique value in any manner. I.e., you're free to use it in any way
you like.
> What kind of performance hit do I take trapping to PALcode?
Switching to PALmode is "fast". I don't have any numbers that measure
this overhead alone, but on a 175MHz Alpha (DEC 3000/600) machine the
overhead for rdps or rdunique (I forgot which) was 13 cycles (assuming
a warm cache). Note that the Alpha CPUs have shadow registers in
PALmode, so in many cases the PALcode itself doesn't have to access
memory at all. I don't know the implementation details, but AFAIK,
entering PALmode is not much more than flipping a bit in the CPU. The
biggest performance hit seems to come from the various scheduling and
synchronization restrictions inside PALmode. See the hardware
reference for all the gory details (and I mean _gory_... ;-)
> I ask because I was thinking of changing the LinuxThreads code to use
> this for its thread id, rather than doing some screwy stack pointer
> lookup nonsense as is necessary for other platforms.
> Anyone see a problem with this?
I think that is exactly what it is designed for.
--david