This is the mail archive of the
mailing list for the Guile project.
Re: GUILE's GC - why we struggling to solve already solved problems ? (was Re: finding the top of the stack in linux)
- To: djurfeldt at nada dot kth dot se, mdj at mdj dot nada dot kth dot se
- Subject: Re: GUILE's GC - why we struggling to solve already solved problems ? (was Re: finding the top of the stack in linux)
- From: "Khimenko Victor" <guile at khim dot sch57 dot msk dot ru>
- Date: Mon, 31 Jul 2000 23:32:57 +0400 (MSD)
- Cc: hanwen at cs dot uu dot nl, guile at sourceware dot cygnus dot com, crayc at kiwi dot pyro dot net
- Organization: MCCME
- References: <firstname.lastname@example.org> <email@example.com> <ABlUpSv8P1@khim.sch57.msk.ru>
28-Jul-00 03:06 you wrote:
> "Khimenko Victor" <firstname.lastname@example.org> writes:
>> But why the hell we are [...] not even using clearly
>> appropriate parts (like stack placement finding subroitine) from ALREADY
>> existing and TESTED solutions.
>> we still can use parts of it to determine stack placement on
>> different systems.
> Would you be willing to cut out and prepare the stack finding code for
I will try to do it. It's not trivial, unfortunatelly. It's easy to cut this
code. It's MUCH harder to do so correct. As you can guess it's big pile of
#ifdef's (if it's Linux then we do it this way, if it's HP-UX then that way
and if it's Win32 then still another code is used) and so we have verification
problem :-/ Plus there are other question: how to do this - manual cut and
paste with tuning or script to convert from GC_ to scm_GC prefix and strip
out unneeded code from appropriate .h and .c files ? Manual way is easier
but then we'll need to repeat this process once every month or two (when new
version of BGC is out).
> You don't need special Guile knowledge to do that. Only make sure
> that identifiers are either static or have the prefix scm_.
Yes, but there are compileability problem - see above :-/
> The interface for finding top of main stack simply needs to return a
> pointer. We need to discuss the interface for finding the top for the
> rest of the threads.