scm_remember_upto_here asm volatile

scm_remember_upto_here asm volatile

[Kevin Ryde]

I was contemplating scm_remember_upto_here_1 and friends and wondered
if thought had been given to doing them in gcc as

    #define scm_remember_upto_here_1(x)             \
      do {                                          \
        asm volatile ("" : : "g" (x));              \
      } while (0)

    #define scm_remember_upto_here_2(x, y)          \
      do {                                          \
        scm_remember_upto_here_1 (x);               \
        scm_remember_upto_here_1 (y);               \
      } while (0)

"volatile" stops the asm being moved, though it can still go dead.
"g" will mean the value isn't forced into a register, a stack
reference is ok.  (Though gcc quite likes bringing things into
registers.)

Avoiding function calls should make the resulting code a little
smaller and faster.  numbers.o comes down from 45k to 43k for me (i386
debian gcc 3.2 -O3), which is not huge but better than a poke in the
eye with a burnt stick.

Unfortunately I can't see how to do the varargs scm_remember_upto_here
the same way.  But it's not used in the main guile code as far as I
can tell.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: scm_remember_upto_here asm volatile

[Marius Vollmer]

Kevin Ryde <user42@zip.com.au> writes:

> I was contemplating scm_remember_upto_here_1 and friends and wondered
> if thought had been given to doing them in gcc as
> 
>     #define scm_remember_upto_here_1(x)             \
>       do {                                          \
>         asm volatile ("" : : "g" (x));              \
>       } while (0)

I can't think of or remember any arguments against this, other than
that I have grown a bit vary of "asm", given that my only use of asm
has been quite wrong.  When you are sure that your code does the job,
then, yeah, why not.

But please understand that this is a critical and tricky corner of
Guile.  Bugs might show up on odd platforms and might be very
sensitive to the environment that scm_remember_upto_here is used in.
I tend to be conservative with things like this.  The win is not that
huge, as you, say, but I myself feel a bit unsure about the
correctness.  But I'm not a good judge here, I'd say.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: scm_remember_upto_here asm volatile

[Kevin Ryde]

Marius Vollmer <mvo@zagadka.de> writes:
>
> But please understand that this is a critical and tricky corner of
> Guile.  Bugs might show up on odd platforms and might be very
> sensitive to the environment that scm_remember_upto_here is used in.

With the bignum code, is it true that the only problem will be if a gc
starts in another thread at the critical moment?

If currently the gmp code just uses malloc I guess it won't run a gc
from within the mpz functions as such.  That wasn't the case in the
old code though, if I read scm_i_mkbig rightly.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: scm_remember_upto_here asm volatile

[Marius Vollmer]

Kevin Ryde <user42@zip.com.au> writes:

> Marius Vollmer <mvo@zagadka.de> writes:
> >
> > But please understand that this is a critical and tricky corner of
> > Guile.  Bugs might show up on odd platforms and might be very
> > sensitive to the environment that scm_remember_upto_here is used in.
> 
> With the bignum code, is it true that the only problem will be if a gc
> starts in another thread at the critical moment?

Yes, I would say so.  And since a GC does only run when all other
threads are stopped in a safe place, there won't be any GCs at
critical moments.

Since this is so convenient, I think we should continue to make this
guarantee (that a GC wont happen spontanously).  Mikael?

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: scm_remember_upto_here asm volatile

[Mikael Djurfeldt]

[Answers given "out-of-context"---can't read the thread right now.]

Marius Vollmer <mvo@zagadka.de> writes:

> And since a GC does only run when all other threads are stopped in a
> safe place, there won't be any GCs at critical moments.

That's right.

> Since this is so convenient, I think we should continue to make this
> guarantee (that a GC wont happen spontanously).  Mikael?

Yes, I think this at least gives a simple model for what to expect.

Any other more conservative model might have the advantage to preserve
more freedom to change the GC/thread policy in the future, but will
also need to be much more complex.  Besides, we wouldn't know now what
kind of cautions are important to think about...

(Was that answer intelligible? :)

Mikael


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: scm_remember_upto_here asm volatile

[Kevin Ryde]

[-- Attachment #1: Type: text/plain, Size: 524 bytes --]

In absense of violent objections I made this change, I'm pretty sure
it's right.  A temporary "# %0" or similar can be put in the asm
string to see in the .s output where the operand is actually located
(just to prove that it really is live at the right point).

        * gc.h (scm_remember_upto_here_1, scm_remember_upto_here_2)
        [__GNUC__]: Use volatile asm macros rather than a function call.
        * gc.c (scm_remember_upto_here_1, scm_remember_upto_here_2): Undefine
        macros while defining functions.


[-- Attachment #2: gc.h.upto.diff --]
[-- Type: text/plain, Size: 1246 bytes --]

--- gc.h.~1.110.~	2003-07-29 09:27:59.000000000 +1000
+++ gc.h	2003-08-14 07:05:09.000000000 +1000
@@ -341,6 +341,26 @@
 SCM_API void scm_remember_upto_here_1 (SCM obj);
 SCM_API void scm_remember_upto_here_2 (SCM obj1, SCM obj2);
 SCM_API void scm_remember_upto_here (SCM obj1, ...);
+
+/* In GCC we can force a reference to an SCM with a little do-nothing asm,
+   avoiding the code size and slowdown of an actual function call.
+   __volatile__ ensures nothing will be moved across the reference, and that
+   it won't be optimized away (or rather only if proved unreachable).
+   Unfortunately there doesn't seem to be any way to do the varargs
+   scm_remember_upto_here similarly.  */
+
+#ifdef __GNUC__
+#define scm_remember_upto_here_1(x)             \
+  do {                                          \
+    __asm__ __volatile__ ("" : : "g" (x));      \
+  } while (0)
+#define scm_remember_upto_here_2(x, y)          \
+  do {                                          \
+    scm_remember_upto_here_1 (x);               \
+    scm_remember_upto_here_1 (y);               \
+  } while (0)
+#endif
+
 SCM_API SCM scm_return_first (SCM elt, ...);
 SCM_API int scm_return_first_int (int x, ...);
 SCM_API SCM scm_permanent_object (SCM obj);

[-- Attachment #3: gc.c.upto.diff --]
[-- Type: text/plain, Size: 542 bytes --]

--- gc.c.~1.244.~	2003-04-07 08:05:08.000000000 +1000
+++ gc.c	2003-08-14 07:06:36.000000000 +1000
@@ -656,6 +656,12 @@
  *   scm_remember_upto_here_1 (str);  // str will be alive up to this point.
  */
 
+/* Remove any macro versions of these while defining the functions.
+   Functions are always included in the library, for upward binary
+   compatibility and in case combinations of GCC and non-GCC are used.  */
+#undef scm_remember_upto_here_1
+#undef scm_remember_upto_here_2
+
 void
 scm_remember_upto_here_1 (SCM obj SCM_UNUSED)
 {

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: scm_remember_upto_here asm volatile

[Dirk Herrmann]

Kevin Ryde wrote:

>+  do {                                          \
>+    __asm__ __volatile__ ("" : : "g" (x));      \
>+  } while (0)
>  
>
Hello Kevin,

would you mind to add an explanation of the syntax of that construct? 
For example, what does the "g" mean? Since we don't have many asm 
instructions in guile, it is fair to assume that most of the developers 
don't know about the exact meaning of that construct.

Thanks a lot
Dirk Herrmann




_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: scm_remember_upto_here asm volatile

[Kevin Ryde]

Dirk Herrmann <dirk@dirk-herrmanns-seiten.de> writes:
>
> would you mind to add an explanation of the syntax of that construct?
> For example, what does the "g" mean? Since we don't have many asm
> instructions in guile, it is fair to assume that most of the
> developers don't know about the exact meaning of that construct.

How about the tweak below.  No doubt the gcc manual describes the
overall syntax better than a bit of a comment could do, the aim I
guess would be just to cover the reasoning for why this form does
what's wanted in this context.



/* In GCC we can force a reference to an SCM with a little do-nothing asm,
   avoiding the code size and slowdown of an actual function call.
   Unfortunately there doesn't seem to be any way to do the varargs
   scm_remember_upto_here similarly.

   __volatile__ ensures nothing will be moved across the asm, and it won't
   be optimized away (or only if proved unreachable).  Constraint "g" can be
   used on all processors, it allows any memory, general register, or
   immediate operand.  The actual asm syntax which comes out for it doesn't
   matter, we don't want to use it, just ensure the operand is still
   alive.  */


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: scm_remember_upto_here asm volatile

[Dirk Herrmann]

Kevin Ryde wrote:

>How about the tweak below.  No doubt the gcc manual describes the
>overall syntax better than a bit of a comment could do, the aim I
>guess would be just to cover the reasoning for why this form does
>what's wanted in this context.
>
>
>
>/* In GCC we can force a reference to an SCM with a little do-nothing asm,
>   avoiding the code size and slowdown of an actual function call.
>   Unfortunately there doesn't seem to be any way to do the varargs
>   scm_remember_upto_here similarly.
>
>   __volatile__ ensures nothing will be moved across the asm, and it won't
>   be optimized away (or only if proved unreachable).  Constraint "g" can be
>   used on all processors, it allows any memory, general register, or
>   immediate operand.  The actual asm syntax which comes out for it doesn't
>   matter, we don't want to use it, just ensure the operand is still
>   alive.  */
>  
>
Well, I still don't know what the "g" means, just that it can be used on 
all processors. But, if you think that the GCC manual describes it 
clearly enough and don't want to copy that documentation, I would 
suggest to add a note 'for an explanation of the asm expression see GCC 
manual of GCC-version xx.xx, chapter xx'. This makes it easy to find the 
necessary explanation plus has the advantage that in case of changes in 
GCC to that syntax, it is clearly stated to which version of GCC the 
implementation was tailored. If the GCC folks enumerate the versions of 
their assembly syntax definition, this version number would even be 
better. Suggestion:

/* In GCC we can force a reference to an SCM with a little do-nothing asm,
   avoiding the code size and slowdown of an actual function call.
   Unfortunately there doesn't seem to be any way to do the varargs
   scm_remember_upto_here similarly.

   __volatile__ ensures nothing will be moved across the asm, and it won't
   be optimized away (or only if proved unreachable).  For an explanation
   of the asm expression see GCC manual of GCC-version xx.xx, chapter xx.  */


Friendly regards
Dirk Herrmann



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: scm_remember_upto_here asm volatile

[Kevin Ryde]

Dirk Herrmann <dirk@dirk-herrmanns-seiten.de> writes:
>
> Well, I still don't know what the "g" means,

Oh, well, it's pretty easy actually, a string for the asm instruction,
then output operands and input operands, with operand constraints
saying what register or memory etc is acceptable.  In this case "g" (x)
means an input operand, located anywhere.

> changes in GCC to that syntax,

I wouldn't be too worried about that, asm has been a documented
feature for a long time and unlikely to change in incompatible ways.
It certainly goes back to gcc 2.7.2 in this form, and probably
earlier.

In any case I amended to:


/* In GCC we can force a reference to an SCM by making it an input to an
   empty asm.  This avoids the code size and slowdown of an actual function
   call.  Unfortunately there doesn't seem to be any way to do the varargs
   scm_remember_upto_here like this.

   __volatile__ ensures nothing will be moved across the asm, and it won't
   be optimized away (or only if proved unreachable).  Constraint "g" can be
   used on all processors and allows any memory or general register (or
   immediate) operand.  The actual asm syntax doesn't matter, we don't want
   to use it, just ensure the operand is still alive.  See "Extended Asm" in
   the GCC manual for more.  */


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel