[Top][All Lists]

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

Re: gc issues

From: Michael Livshin
Subject: Re: gc issues
Date: 15 Sep 2000 00:04:17 +0300
User-agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (20 Minutes to Nikko)

address@hidden (Carl R. Witty) writes:

> Michael Livshin <address@hidden> writes:
> > 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 for x86 with -O2); they emit the same write instruction as
> non-volatile writes.

one more wrong assumption struck down; cool.

> > > 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.

on ix86?  I'm not sure.  well, I probably should just check the
assembly instead of spamming the list...


This computer thanks you for your attention.

reply via email to

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