Re: [Xsb-development] Re: buglet related to attributed variables

[Terrance S. <ts...@cs...>]

The code isn't mine, only the comment.

And by the way, I'm glad you figured out about handling the interrupts
in the proceed.  Not that I had.   I slapped my forehead when I read it.
Maybe this shows a weird aspect of cognition...

As far as comment goes, It does look line something is wrong.  If
int_val(cell(interrupt_reg)) is true, then intercept() should be
called, which should call handle_interrupts -- through

'_$attv_int'(Intlist, Call) :-
	handle_interrupts(Intlist),
	call_c(Call).

and then the continuation via Call.  But the actual setting of lpcreg
to get_ep(PSC) appears to be omitted.  So I'll need to spend some time
with it tomorrow, and I'll try to tease out what should be done.

By the way, I do think that it would be much clearer if we had
separate arrays for the flags and the interrupts, rather than adding +
32 to the types to get the various entry points.

Terry


On Thu, 21 Apr 2005, David Warren wrote:

> Terrance Swift writes:
>  > ..so unless somebody else wants to step up to the plate I'll start making
>  > changes to check the interrupt register in cut, and throw an error. I'll
>  > hold off on actually handling the interrupts for now...
>
> That's fine.  I have realized (rather late now, it being more than 20
> years since I added interrupt handling to SBProlog) that we can also
> check for interrupts and handle them in the proceed instruction, not
> only in the call and execute instructions.  So I have now added code
> to handle interrupts in the proceed instruction.  That happens to
> solve the problem that started this whole mess, since the variable
> binding was done in a predicate that then returned (using a proceed)
> up to where the cut was done.  Now the attributed-variable interrupt
> is handled in the proceed and failure happens there, before the cut.
>
> Of course, this doesn't solve the general problem.  It just makes it a
> little less likely.  Bart's examples of inlined unification followed
> by another inline will still be incorrectly handled.  So Terry's
> addition of a check to cut is still wise, I think.
>
> However, I did come across some code in the interrupt handler that I
> do NOT understand.  I'm wondering if one of you (my guess is Terry, if
> anyone, since it's attv related) knows about this code, or can figure
> it out better than I, and can help.  It is the following code (in
> call_sub(PSC) in emudef.h) to handle the attv interrupt condition:
>
>      } else if (int_val(cell(interrupt_reg))) {                         \
>         synint_proc(CTXTc PSC, MYSIG_ATTV);		                \
>         lpcreg = pcreg;							\
>         /* Set PSC to '_$attv_int'/2, so that the later call of	*/	\
>         /* intercept(PSC) will set the return point, pcreg, to	*/	\
>         /* '_$attv_int'/2.  -- I don't understand this-dsw	*/	\
>         PSC = (Psc) flags[MYSIG_ATTV+INT_HANDLERS_FLAGS_START];		\
>      }
>
> My problem is with the last line:
>         PSC = (Psc) flags[MYSIG_ATTV+INT_HANDLERS_FLAGS_START];
> and the comment trying to explain why it is there.
>
> PSC is the parameter to the macro and is the psc record of the
> predicate being called.  The call to synint_proc builds the call term
> on the heap, sets the general registers appropriately and seto ts
> pcreg to point to the entry point of the interrupt routine predicate.
> Cool.  But now what does the assignment to PSC do?  My tracing seems
> to indicate that this assigns a value to a local variable in the block
> that executes the call WAM instruction, which is immediately exited
> and released.  I.e., this assignment has no effect.  The comment is
> supposed to explain why it is there, I assume, but I don't understand
> what it might be saying.  Why might we want to execute the
> '_$attv_int'/2 predicate?  So 2 things:
>
> Can anyone decipher the comment to know what this code might be doing
> or trying to do?
>
> I've deleted the code and run the testsuite, and it passes all the
> attv tests.  Is this enough of a test for me to be sure the deletion
> is OK?
>
> -David
>