Re: [9fans] extern register
On Sun, Jul 20, 2014 at 3:42 AM, cinap_len...@felloff.net wrote: removed the saving and restoring of DS/ES/FS/GS segment registers... they have no effect in long mode Actually FS and GS do work in long mode. Since we don't need them for TLS, maybe we can do something useful with them. -- Aram Hăvărneanu
Re: [9fans] extern register
it doenst matter to runtime what data segment selectors have been loaded in the segment registers in long mode. we initially load them with null seletors and then never touch them again. but the processor *does* check the selectors index when you load a selector into a segment register! the reason i removed the saving and restoring is that i can stop worrying about bad data selectors when devproc or noted sets the ureg of a process. we had todo this on 386 because otherwise the process would #GP when trying to restore the bad selectors. now without restoring the segment registers, it cant #GP and nothing needs to be checked. for GS/FS theres new GS_BASE and FS_BASE msr register that the kernel can set to change GS and FS segment offsets affetcing the offset used by GS and FS segment prefixes. but the kernel would need to switch these msrs in and out for each process and provide a interface for userspace to set ther base. you will need this for something like linuxemu. -- cinap
Re: [9fans] extern register
I don't have any opinion on whether R14 and R15 should be saved, but the justification posted in the top post seems weak. The stack is already per-process data. One can use _tos for per-proc data, just like privalloc(2) does. -- Aram Hăvărneanu
Re: [9fans] extern register
On 19 July 2014 02:57, cinap_len...@felloff.net wrote: would it make sense to save and restore the two registers on syscall entry/exit, so userspace programs could make use of them for per process data? Good question. None of the others need to be saved and restored because they are defined to be dead on entry to a function, but you're right that rule doesn't really apply to extern register, and they could be useful. _tos only works when every process has at least one stack always at the same fixed virtual address. On the other hand, a kernel that provides an alternative to that would also know to save and restore extern registers.
Re: [9fans] extern register
On Sat, Jul 19, 2014 at 2:42 PM, Charles Forsyth charles.fors...@gmail.com wrote: _tos only works when every process has at least one stack always at the same fixed virtual address. Isn't this always true? -- Aram Hăvărneanu
Re: [9fans] extern register
On Sat Jul 19 10:40:49 EDT 2014, ara...@mgk.ro wrote: On Sat, Jul 19, 2014 at 2:42 PM, Charles Forsyth charles.fors...@gmail.com wrote: _tos only works when every process has at least one stack always at the same fixed virtual address. Isn't this always true? does anyone have a use case for extern register in user space? come to think of it, extern register is defined to be one register per mach, which is a bit of a stretch for user space. - erik
Re: [9fans] extern register
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
Re: [9fans] extern register
ok, i preserve user R14 and R15 now. also removed the saving and restoring of DS/ES/FS/GS segment registers... they have no effect in long mode and there are no 32 bit tasks. someone write a proof of concept program that communicates with another process by morsing data on the segment registers by loading them with NULLSEL and UDSEL :) -- cinap
[9fans] extern register
the amd64 compiler reserves R14 and R15 for extern register declarations. these are used by the kernel for the mach and up pointers, but currently are not preserved during system calls. would it make sense to save and restore the two registers on syscall entry/exit, so userspace programs could make use of them for per process data? -- cinap
Re: [9fans] extern register
On Fri Jul 18 21:58:37 EDT 2014, cinap_len...@felloff.net wrote: the amd64 compiler reserves R14 and R15 for extern register declarations. these are used by the kernel for the mach and up pointers, but currently are not preserved during system calls. would it make sense to save and restore the two registers on syscall entry/exit, so userspace programs could make use of them for per process data? i think after some experience (i.e. mistakes) the answer is probablly, no. the compiler needs to know for the kernel that r14 and r15 are special and not allocate them for the kernel, but what about userland? what about libraries that are shared between them? one can work around these problems by compiling all libraries twice, etc. but these are painful compromises. in reality, there is only one place in the code that i know of that chews through 15 or more registers, and that's the alpha drawing code in libmemdraw. so the solution of just limiting the compiler to r0-r13 seems to be pretty effective for what we're doing. - erik
Re: [9fans] extern register
On Fri Jul 18 22:05:32 EDT 2014, quans...@quanstro.net wrote: On Fri Jul 18 21:58:37 EDT 2014, cinap_len...@felloff.net wrote: the amd64 compiler reserves R14 and R15 for extern register declarations. these are used by the kernel for the mach and up pointers, but currently are not preserved during system calls. would it make sense to save and restore the two registers on syscall entry/exit, so userspace programs could make use of them for per process data? i think after some experience (i.e. mistakes) the answer is probablly, no. the compiler needs to know for the kernel that r14 and r15 are special and not allocate them for the kernel, but what about userland? what about libraries that are shared between them? one can work around these problems by compiling all libraries twice, etc. but these are painful compromises. in reality, there is only one place in the code that i know of that chews through 15 or more registers, and that's the alpha drawing code in libmemdraw. so the solution of just limiting the compiler to r0-r13 seems to be pretty effective for what we're doing. i realize i didn't quite answer the question as asked. restoring the registers is independent of the compiler. so yes, you're right! the registers should be restored. but at least you know why it's not a disaster that they are not. - erik
Re: [9fans] extern register
so, we say r14 and r15 arent really special for user programs. and its just a c compiler implementation detail that it doesnt allocate these registers, but assembly code can freely use them for scratch space or whatever. extern register will not work in userspace c programs because syscalls will trash these registers. makes any sense? -- cinap
Re: [9fans] extern register
isnt that contradicting what you just said? -- cinap
Re: [9fans] extern register
On Fri Jul 18 22:34:43 EDT 2014, cinap_len...@felloff.net wrote: isnt that contradicting what you just said? i didn't think so. restated: you could restore the registers, and that would be right proper, but it wouldn't make a difference unless you're using some fancy assembly, or a different compiler; it doesn't give the compiler more freedom. - erik
Re: [9fans] extern register
On Fri Jul 18 22:28:12 EDT 2014, cinap_len...@felloff.net wrote: so, we say r14 and r15 arent really special for user programs. and its just a c compiler implementation detail that it doesnt allocate these registers, but assembly code can freely use them for scratch space or whatever. extern register will not work in userspace c programs because syscalls will trash these registers. makes any sense? certainly. speaking for myself, the model that r14 and r15 are off limits for esoteric reasons is preferrable, given the quite limited maximum benefit, to the complications of sneaking by the limitation. obviously, the mips port avoided this by never needing 28 live registers at once. - erik
