This is the mail archive of the guile@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] |
KP = Ken Pizzini <ken@halcyon.com> MD = Mikael Djurfeldt <mdj@nada.kth.se> KP> I am bothered by the warnings that gcc emits about some variables KP> in libguile/eval.c potentially being harmed by setjmp() because KP> they are not being declared as volatile. ... MD> I'd prefer to ignore this problem as long as possible, i.e. until MD> continuations doesn't work on some machine out there! I don't like the feel of that approach. I'll live with it if I must, but I'd rather find an approach which is intermediate between the alleged speed hit of simply using volatile and the alleged danger of the code remaining as it is. MD> This is because making x and env volatile in the evaluator could have MD> very bad effects on performance. ... MD> BTW, I have some problems understanding your suggested changes. MD> Wouldn't it be better to declare the arguments as volatile, e.g.: MD> MD> SCM_CEVAL (volatile SCM arg_x, ...) MD> { MD> [register] SCM x = arg_x; MD> MD> and use this unqualified/register x in the code? MD> One should then restore x from arg_x after each setjmp. The stuff in SCM_CEVAL was a stub that I didn't remove from my sample patch. Look at what I did in SCM_APPLY to see what I am really proposing. I am not completely clear that I can extend the "wrap in helper function" approach efficiently to SCM_CEVAL, but am willing to try if it is felt that my SCM_APPLY change is acceptable. --Ken Pizzini