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]

Re: z


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