Re: guile 1.5.2 build on ia64 ... successful gc'ing

[Rob Browning]

stefan <address@hidden> writes:

> Same came to my mind. But the SCM_FLUSH_REGISTER_WINDOWS definition is
> meant to fulfill register flushing. Might be confusing to do something
> else on IA-64. 

Right.  I didn't mean to imply that that macro should be redefined for
ia64, but that that macro presented a precedent for arch specific
bits.

> That means on a ia64 we have something which is unique. No other machine
> has something like it (not sure if this is really true).  This is a good
> reason to introduce some new definition, like SCM_SCAN_BACKING_STORE ...
> just a proposal.

Exactly.  I figured we might want something like this, but I wasn't
sure what an appropriate name would be, and where it should go.  I
also didn't know if the relevant code could possibly be refactored to
allow for a more general operation that covered both.

Am I correct here that in both the sparc and ia64 case, what you're
really trying to do is make sure *all* the state is available
somewhere where the GC can see it?  If so, could we have something
like SCM_FLUSH_ARCH_STATE and/or SCM_SCAN_ARCH_STATE?

> The "make check" does it, and fails as well. With the changes to
> guile-1.5.3 I can start investigating the above problem...

OK, I've just finished adding the patches to my 1.5 tree.  I'll patch
them over to the dev tree and then commit.  I should have a 1.5.3
ready today or tomorrow.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD