<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 20, 2018 at 11:47 PM, Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br><div dir="ltr">Hi Javier,<div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 20, 2018 at 2:04 PM, Javier Pimás <span dir="ltr"><<a href="mailto:elpochodelagente@gmail.com" target="_blank">elpochodelagente@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br><div dir="ltr">That's a perfect description. The isr handler calls signalSemaphoreWithIndex and<div>quietly returns. In the image there is one process waiting on each interrupt (smalltalk)</div><div>semaphore, with the smalltalk handling code for that interrupt. Of course, this only </div><div>works for external interrupts, and not for exceptions (normally when you get a processor</div><div>exception while running smalltalk code it means something very wrong just happened, </div><div>so you cannot just go back to it). IIRC for paging we used alienffi callbacks, but there</div><div>is a trick, you have to know a bit about the code triggering the page faults, in order to</div><div>assure that it is safe to reenter the vm.</div></div></blockquote><div><br></div><div>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?</div></div></div></div></blockquote><div><br></div><div>Yes! I think we showed it in the great Smalltalks conf at CdU almost a decade ago. The limitation was to raise the #PF in a controlled way (in that case, a primitive to read arbitrary memory position). When the exception was raised, the native code handler saved the VM state (in a very hacky way), and reentered through an alien callback. In smalltalk it was possible to place a halt in the handler and debug everything normally. The exception-causing code was left paused until the callback went back, moment at which the VM state was "restored" (I can't remember the details, but I guess it only made sense to restore a subset of the interpreter state).</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Handling exceptions is a topic for research. But for that it is necessary to rethink in which<br></div><div>situations exceptions could happen. For example, could a cogvm generate a zero division</div><div>exception? If not, then a #DE might mean that the vm just crashed.</div></div></blockquote><div><br></div><div>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.</div></div></div></div></blockquote><div><br></div><div>Yes, that would make sense here too. Remember that until now we havent done any research in protection mechanisms under squeaknos, all the code runs in ring 0, so there's no OS/user separation. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>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.</div></div></div></div></blockquote><div><br></div><div>We still have to determine how to implement the support for the heartbeat thread at all in squeaknos, but yes, when that is done error checking during threaded ffi seems complex but doable.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 19, 2018 at 5:58 PM, Jecel Assumpcao Jr. <span dir="ltr"><<a href="mailto:jecel@merlintec.com" target="_blank">jecel@merlintec.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Eliot,<br>
<br>
> The thing I do not understand about SqueakNOS and responding to an interrupt<br>
> at an arbitrary time is how one expects to deal with handling an interrupt during<br>
> some sequence of instructions that is between suspension points, such as mid<br>
> way through a store check which is adding an object to the remembered set, or<br>
> mid way through a message lookup.  Does SqueakNOS actually use the<br>
> enable/disable interrupts approach?<br>
<br>
If I understood correctly, the only thing the VM does when it gets an<br>
interrupt from the 8259 chips is to signal a corresponding semaphore and<br>
immediately return to what it was doing. At some point in the future the<br>
code waiting for the semaphore gets scheduled and then run by the VM,<br>
but at that instant none of the problems you mention should happen. It<br>
is that code that is resposible for telling the 8259s that the interrupt<br>
has been handled so only then can it receive the next one.<br>
<br>
-- Jecel<br>
<br>
<a href="http://wiki.squeak.org/squeak/1762" rel="noreferrer" target="_blank">http://wiki.squeak.org/squeak/<wbr>1762</a> (see "SqueakNOS IRQ Handling" in the<br>
middle of this page)<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="m_2901136843529100242m_-4830400407191778160m_-8305302234610591319gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Javier Pimás<br>Ciudad de Buenos Aires</div></div>
</div>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="m_2901136843529100242m_-4830400407191778160gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="m_2901136843529100242gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Javier Pimás<br>Ciudad de Buenos Aires</div></div>
</div></div>