[Top][All Lists]
[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
- gc issues, Dirk Herrmann, 2000/09/13
- Re: gc issues, Michael Livshin, 2000/09/13
- Re: gc issues, Dirk Herrmann, 2000/09/13
- Re: gc issues, Michael Livshin, 2000/09/13
- Re: gc issues, Dirk Herrmann, 2000/09/13
- Re: gc issues, Carl R. Witty, 2000/09/13
- Re: gc issues, Michael Livshin, 2000/09/13
- Re: gc issues,
Carl R. Witty <=
- Re: gc issues, Michael Livshin, 2000/09/14
- Re: gc issues, Jim Blandy, 2000/09/15
- Re: gc issues, Michael Livshin, 2000/09/13
- Re: gc issues, Michael Livshin, 2000/09/14
- Re: gc issues, Jim Blandy, 2000/09/14
- Re: gc issues, Michael Livshin, 2000/09/14
- Re: gc issues, Dirk Herrmann, 2000/09/14
- Re: gc issues, Michael Livshin, 2000/09/16
- Re: gc issues, Dirk Herrmann, 2000/09/19
- Re: gc issues, Michael Livshin, 2000/09/19