• Sean Kelly (11/11) Dec 30 2005 With the recent talk about real-time programming and GC I've begun
• Chris Lajoie (4/14) Dec 31 2005 As a fan of your posts I *really* wish I knew what the hell you were
• Sean Kelly (15/29) Dec 31 2005 LOL. Some features such as incremental garbage collection require very
• pragma (12/22) Dec 31 2005 Somehow I gather that using thread-local storage isn't going to get the
• Sean Kelly (22/34) Jan 02 2006 I suppose so. Though it might be really nice if the assembler spec
• Sean Kelly (6/6) Jan 03 2006 Another feature that might be nice is language support for TLS. The Sun...

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

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

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

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

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

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