On Sat, Jul 19, 2014 at 4:55 PM, erik quanstrom <quans...@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
