[Vm-dev] SqueakNOS interrupts (was: FFI callback for interrupts in Raspberry)

[Eliot Miranda]

Hi Javier,

On Tue, Feb 20, 2018 at 2:04 PM, Javier Pimás <elpochodelagente at gmail.com>
wrote:

>
> That's a perfect description. The isr handler calls
> signalSemaphoreWithIndex and
> quietly returns. In the image there is one process waiting on each
> interrupt (smalltalk)
> semaphore, with the smalltalk handling code for that interrupt. Of course,
> this only
> works for external interrupts, and not for exceptions (normally when you
> get a processor
> exception while running smalltalk code it means something very wrong just
> happened,
> so you cannot just go back to it). IIRC for paging we used alienffi
> callbacks, but there
> is a trick, you have to know a bit about the code triggering the page
> faults, in order to
> assure that it is safe to reenter the vm.
>

Can you say more about page faults?  Can you handle these in Smalltalk?  (I
would think one can't)  Do you instead want a dedicated page fault handler?


> Handling exceptions is a topic for research. But for that it is necessary
> to rethink in which
> situations exceptions could happen. For example, could a cogvm generate a
> zero division
> exception? If not, then a #DE might mean that the vm just crashed.
>

Well, for SqueakNOS I guess it makes sense that the VM should never
generate an exception.  But if one has a Smalltalk system with an FFI then
FFI calls might generate exceptions and it is /much/ nicer to catch the
error and report it back, a bit like a primitive failure, rather than
crashing the VM.  So I modified the VisualWorks VM to handle exceptions
such as illegal instruction and bus violation and if these occurred during
an FFI call (identified simply by setting and clearing a flag when in an
FFI call) the handler arranged that the FFI call "failed" and the exception
code was reported.

This gets more complicated when the VM is threaded.  Here one still needs
to set and reset the flag when an FFI call is in progress, because the
threading on FFI calls works by the heartbeat thread noticing that the VM
is in an FFI call and then starting up another thread to run the VM.  So
the exception handler needs to check got both the "in FFI call" flag when
on the current VM thread, and for occurring in some other thread.  And if
the exception happens in some other thread and that thread is known to the
VM and is in fact a thread that is currently doing an FFI call then again
the exception can be collected and the FFI call can "fail" and answer the
exception information.


>
>
> On Mon, Feb 19, 2018 at 5:58 PM, Jecel Assumpcao Jr. <jecel at merlintec.com>
> wrote:
>
>>
>> Eliot,
>>
>> > The thing I do not understand about SqueakNOS and responding to an
>> interrupt
>> > at an arbitrary time is how one expects to deal with handling an
>> interrupt during
>> > some sequence of instructions that is between suspension points, such
>> as mid
>> > way through a store check which is adding an object to the remembered
>> set, or
>> > mid way through a message lookup.  Does SqueakNOS actually use the
>> > enable/disable interrupts approach?
>>
>> If I understood correctly, the only thing the VM does when it gets an
>> interrupt from the 8259 chips is to signal a corresponding semaphore and
>> immediately return to what it was doing. At some point in the future the
>> code waiting for the semaphore gets scheduled and then run by the VM,
>> but at that instant none of the problems you mention should happen. It
>> is that code that is resposible for telling the 8259s that the interrupt
>> has been handled so only then can it receive the next one.
>>
>> -- Jecel
>>
>> http://wiki.squeak.org/squeak/1762 (see "SqueakNOS IRQ Handling" in the
>> middle of this page)
>>
>
>
>
> --
> Javier Pimás
> Ciudad de Buenos Aires
>
>


-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20180220/4ebef6ad/attachment.html>