guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gc issues


From: Carl R. Witty
Subject: Re: gc issues
Date: 14 Sep 2000 13:02:20 -0700

Michael Livshin <address@hidden> writes:

> address@hidden (Carl R. Witty) writes:
> 
> > Dirk Herrmann <address@hidden> writes:
> > 
> > > I suggest to use an alternative macro:
> > > 
> > > extern volatile SCM scm_dummy;  /* never read, only written */
> > > #define scm_remember_object(obj) (scm_dummy = (obj))
> 
> I'm not at all sure that writing a volatile location is cheaper than
> calling an empty function with one argument.  in fact, function should
> cost less, for caching reasons -- the top of the stack is always in
> dcache, and `scm_remember' has a non-zero chance to be in icache.  a
> store to a volatile location is supposed to force a commit.  I think.

There's a pretty good chance that scm_dummy is in dcache.  Also,
volatile writes don't do any specific cache manipulation (at least for
gcc 2.7.2.3 for x86 with -O2); they emit the same write instruction as
non-volatile writes.

> > When compiling for gcc, you could use something like (untested):
> > 
> > #define scm_remember_object(obj) (asm("" : : "r"(obj)))
> > 
> > which basically means exactly "make sure this value is in some
> > register at this point in the code".
> 
> wow.  portable assembly code!
> 
> neat, except it's probably unadvisable for ix86, since there are few
> registers and `obj' might actually be on the stack and not need the
> treatment at all.  (hmmm, I wonder if you can somehow test for it in
> GCC -- that would be very cool).

I think my solution is superior to either the call to scm_remember()
or the store to scm_dummy; both of those have to load the variable
into a register anyway.

> -- 
> You have a tendency to feel you are superior to most computers.

Well, most days, anyway.

Carl


reply via email to

[Prev in Thread] Current Thread [Next in Thread]