This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

continuations


Hello!

It looks like people on architectures where SCM_STACK_GROWS_UP is defined
should get warning messages like:
  grow_throw: check if SCM growth[100]; being optimized out

The reason is as follows:  In scm_call_continuation there is stack space
allocated in form of a local array to copy the continuation in.  However,
there seems to be fear that the compiler might optimize that local array
away, thus a test was added that checks, whether the stack has really
grown by the corresponding amount.  But this check seems to be broken on
architectures where SCM_STACK_GROWS_UP is defined, since even in this case
the _base_ address of the local array is compared with the previous top of
the stack.  The situation looks like follows:

used symbols:
.    : arbitrary stack content
|    : Some stack address that is considered 'top'
[--] : a local array, allocated on the stack


Assume the stack grows in this --> direction. 

This is what the stack looks like:     ....|..[----------]

              1) previous top of the stack ^  
              2) array base address           ^
              3) actual new top of the stack             ^


Since 1) and 2) are compared rather than 1) and 3), people should get
warning messages on those architectures.  Can anybody confirm this, or am
I completely wrong here?  Is there anybody who regularly gets the above
warning messages when calling continuations?

Just for comparison, if the stack grows down, everything is OK:


Assume the stack grows in this <-- direction. 

This is what the stack looks like:     [----------]..|...

        1) previous top of the stack                 ^  
        2) array base address          ^

In this case, the test would find that the previous top of the stack and
the array base address do have the desired distance.  For sparc solaris
and i386 linux this is the case.

Best regards
Dirk Herrmann


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]