Re: [9fans] extern register

["Aram Hăvărneanu" <aram.h@mgk.ro>]

On Sat, Jul 19, 2014 at 4:55 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> does anyone have a use case for extern register in user space?

Well Go uses it, but the meaning is different than in the Plan 9
kernel; they reused it for a different storage class.

In Go, there were two external register variables, g and m (now
there is only one for reasons outside the scope of this discussion).
These variables are proc-local as oposed to mach-local. To make a
streched analogy, a proc is to Go as a mach is to the kernel. Both
are some "entities" which can "run" other schedulable entities (Go
now has g's, m's, and p's, so the analogy no longer holds, but that
was the original meaning).

On arm, these variables are kept in registers on all operating
systems. On 386 and amd64, non-Plan 9 systems use a form of TLS to
keep these variables. TLS usually requires libc.so and ld.so
interaction (ugh), so since Go doesn't usually use these, it usually
executes some system call which sets up the base segment registers
to some heap-allocated memory, and then accesses this space using
the segment registers.

On systems which don't have these special system calls, the base
registers are usually initialized by the kernel/libc.so/ld.so with
enough space for some slots, so the access is the same, only without
initialization.

Plan 9 has no such nonsense; the stack is at a fixed, and known
address, so these variables can be kept on the stack. I recently
simplified this for the plan9/386 Go port and made the plan9/amd64
Go port use the same mechanism.

-- 
Aram Hăvărneanu