* scm_remember_upto_here asm volatile
@ 2003-05-11 22:19 Kevin Ryde
2003-05-17 20:26 ` Marius Vollmer
0 siblings, 1 reply; 10+ messages in thread
From: Kevin Ryde @ 2003-05-11 22:19 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: scm_remember_upto_here asm volatile 2003-05-11 22:19 scm_remember_upto_here asm volatile Kevin Ryde @ 2003-05-17 20:26 ` Marius Vollmer 2003-05-19 0:24 ` Kevin Ryde 0 siblings, 1 reply; 10+ messages in thread From: Marius Vollmer @ 2003-05-17 20:26 UTC (permalink / raw) Cc: guile-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: scm_remember_upto_here asm volatile 2003-05-17 20:26 ` Marius Vollmer @ 2003-05-19 0:24 ` Kevin Ryde 2003-06-01 18:47 ` Marius Vollmer 0 siblings, 1 reply; 10+ messages in thread From: Kevin Ryde @ 2003-05-19 0:24 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: scm_remember_upto_here asm volatile 2003-05-19 0:24 ` Kevin Ryde @ 2003-06-01 18:47 ` Marius Vollmer 2003-06-01 19:29 ` Mikael Djurfeldt 0 siblings, 1 reply; 10+ messages in thread From: Marius Vollmer @ 2003-06-01 18:47 UTC (permalink / raw) Cc: Mikael Djurfeldt 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: scm_remember_upto_here asm volatile 2003-06-01 18:47 ` Marius Vollmer @ 2003-06-01 19:29 ` Mikael Djurfeldt 2003-08-13 21:09 ` Kevin Ryde 0 siblings, 1 reply; 10+ messages in thread From: Mikael Djurfeldt @ 2003-06-01 19:29 UTC (permalink / raw) Cc: guile-devel [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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: scm_remember_upto_here asm volatile 2003-06-01 19:29 ` Mikael Djurfeldt @ 2003-08-13 21:09 ` Kevin Ryde 2003-08-23 10:32 ` Dirk Herrmann 0 siblings, 1 reply; 10+ messages in thread From: Kevin Ryde @ 2003-08-13 21:09 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: scm_remember_upto_here asm volatile 2003-08-13 21:09 ` Kevin Ryde @ 2003-08-23 10:32 ` Dirk Herrmann 2003-08-25 23:48 ` Kevin Ryde 0 siblings, 1 reply; 10+ messages in thread From: Dirk Herrmann @ 2003-08-23 10:32 UTC (permalink / raw) Cc: guile-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: scm_remember_upto_here asm volatile 2003-08-23 10:32 ` Dirk Herrmann @ 2003-08-25 23:48 ` Kevin Ryde 2003-08-27 4:28 ` Dirk Herrmann 0 siblings, 1 reply; 10+ messages in thread From: Kevin Ryde @ 2003-08-25 23:48 UTC (permalink / raw) Cc: guile-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: scm_remember_upto_here asm volatile 2003-08-25 23:48 ` Kevin Ryde @ 2003-08-27 4:28 ` Dirk Herrmann 2003-08-27 23:49 ` Kevin Ryde 0 siblings, 1 reply; 10+ messages in thread From: Dirk Herrmann @ 2003-08-27 4:28 UTC (permalink / raw) Cc: guile-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: scm_remember_upto_here asm volatile 2003-08-27 4:28 ` Dirk Herrmann @ 2003-08-27 23:49 ` Kevin Ryde 0 siblings, 0 replies; 10+ messages in thread From: Kevin Ryde @ 2003-08-27 23:49 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2003-08-27 23:49 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2003-05-11 22:19 scm_remember_upto_here asm volatile Kevin Ryde 2003-05-17 20:26 ` Marius Vollmer 2003-05-19 0:24 ` Kevin Ryde 2003-06-01 18:47 ` Marius Vollmer 2003-06-01 19:29 ` Mikael Djurfeldt 2003-08-13 21:09 ` Kevin Ryde 2003-08-23 10:32 ` Dirk Herrmann 2003-08-25 23:48 ` Kevin Ryde 2003-08-27 4:28 ` Dirk Herrmann 2003-08-27 23:49 ` Kevin Ryde
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).