www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Reserved registers?

reply Sean Kelly <sean f4.ca> writes:
With the recent talk about real-time programming and GC I've begun 
wondering whether there are any x86 registers that can be reserved for 
library use with DMD (and GDC as well I suppose).  The reason I ask is 
that some features such as incremental GC require per-thread storage of 
a memory address (a pointer to GC data, for example), and since the main 
thread is initialized differently from supplementary threads, a fixed 
offset from the stack base address can't be used (not without a stack 
pointer kludge at any rate).  Any suggestions?  I thought I'd ask here 
before digging through reference material or trying to come up with 
something clever :-p


Sean
Dec 30 2005
next sibling parent reply Chris Lajoie <ctlajoie___remove___this___ ___gmail.com> writes:
Sean Kelly wrote:
 With the recent talk about real-time programming and GC I've begun 
 wondering whether there are any x86 registers that can be reserved for 
 library use with DMD (and GDC as well I suppose).  The reason I ask is 
 that some features such as incremental GC require per-thread storage of 
 a memory address (a pointer to GC data, for example), and since the main 
 thread is initialized differently from supplementary threads, a fixed 
 offset from the stack base address can't be used (not without a stack 
 pointer kludge at any rate).  Any suggestions?  I thought I'd ask here 
 before digging through reference material or trying to come up with 
 something clever :-p

As a fan of your posts I *really* wish I knew what the hell you were talking about ;) Chris
Dec 31 2005
parent Sean Kelly <sean f4.ca> writes:
Chris Lajoie wrote:
 Sean Kelly wrote:
 With the recent talk about real-time programming and GC I've begun 
 wondering whether there are any x86 registers that can be reserved for 
 library use with DMD (and GDC as well I suppose).  The reason I ask is 
 that some features such as incremental GC require per-thread storage 
 of a memory address (a pointer to GC data, for example), and since the 
 main thread is initialized differently from supplementary threads, a 
 fixed offset from the stack base address can't be used (not without a 
 stack pointer kludge at any rate).  Any suggestions?  I thought I'd 
 ask here before digging through reference material or trying to come 
 up with something clever :-p

As a fan of your posts I *really* wish I knew what the hell you were talking about ;)

LOL. Some features such as incremental garbage collection require very fast access to an address somewhere in memory. While this specific case *could* be done via an extern (C) call (at the cost of performance), per-thread heaps, thread local storage, etc, need to access a different memory location on a per-thread basis... which basically means the pointer either needs to be stored at a known location on the stack or in a CPU register (since both are swapped out during a context switch). And reserving a CPU register is the recommended way to handle the incremental GC issue as well, since application speed is tightly linked to the number of additional ASM instructions executed when a pointer is modified. Since stack and register manipulation is largely a language implementation issue, I thought it made more sense to ask here than to make any assumptions about stack layout or register use by DMD/GDC. Sean
Dec 31 2005
prev sibling parent reply pragma <pragma_member pathlink.com> writes:
In article <dp577v$gnn$1 digitaldaemon.com>, Sean Kelly says...
With the recent talk about real-time programming and GC I've begun 
wondering whether there are any x86 registers that can be reserved for 
library use with DMD (and GDC as well I suppose).  The reason I ask is 
that some features such as incremental GC require per-thread storage of 
a memory address (a pointer to GC data, for example), and since the main 
thread is initialized differently from supplementary threads, a fixed 
offset from the stack base address can't be used (not without a stack 
pointer kludge at any rate).  Any suggestions?  I thought I'd ask here 
before digging through reference material or trying to come up with 
something clever :-p

Somehow I gather that using thread-local storage isn't going to get the performance benefits you seek... here's my $0.02: Obvious comments about coupling to the compiler, and the incomplete ABI aside, I think you're on the right track with relying on a segment register like SS. I wish I had a proper dissasembler, as I'd be curious if FS or GS get used at all in DMD's output; given it's heritage through DMC and older modes of code generation (?). However, I have no clue what that would do to portabilty to other architectures: I guess you'd fall back on TLS? (it all used to be so much easier when you could just muck with the interrupt vector table however you wanted) - EricAnderton at yahoo
Dec 31 2005
parent reply Sean Kelly <sean f4.ca> writes:
pragma wrote:
 
 Somehow I gather that using thread-local storage isn't going to get the
 performance benefits you seek... here's my $0.02:
 
 Obvious comments about coupling to the compiler, and the incomplete ABI aside,
I
 think you're on the right track with relying on a segment register like SS. I
 wish I had a proper dissasembler, as I'd be curious if FS or GS get used at all
 in DMD's output; given it's heritage through DMC and older modes of code
 generation (?).  However, I have no clue what that would do to portabilty to
 other architectures: I guess you'd fall back on TLS?

I suppose so. Though it might be really nice if the assembler spec included a universal alias for a system register that was guaranteed to not be used by the code generator. The actual register aliased could change from implementation to implementation, but code using that register would be portable. If it were exposed as a global variable (void* perhaps), it could be used in normal code and in ASM blocks without modification. That's what makes sense at first glance anyway--I need to think about all this a bit more. As you're no doubt aware, my goal in all this is to allow the library code to be separable from the compiler and its support routines--that includes both the standard library and the garbage collector. The remaining piece for incremental GC would be code generated for pointer modifications, but perhaps the design for that will come clear once this register issue is sorted out a bit. The requirements for this seem a bit different from Java where the library seems closely linked with the runtime... though from what I understand Java allows the GC to be dynamically replacable (I suppose I'll have to read the spec and see how that works). In any case, I would very much like it if the D standard library does not require any compiler-specific code to be fully functional.
 (it all used to be so much easier when you could just muck with the interrupt
 vector table however you wanted)

True enough :-) Sean
Jan 02 2006
parent Sean Kelly <sean f4.ca> writes:
Another feature that might be nice is language support for TLS.  The Sun 
and Microsoft compilers support this for C++ via __thread and 
__declspec(thread), respectively, so this is definately possible, though 
I suspect it would be nontrivial to implement.  A brief discussion of 
TLS is available here: http://blogs.sun.com/seongbae/


Sean
Jan 03 2006