[Vm-dev] [Pharo-dev] [ANN] PharoNOS

Javier Pimás elpochodelagente at gmail.com
Wed Mar 22 03:59:34 UTC 2017


On Tue, Mar 21, 2017 at 8:28 PM, Eliot Miranda <eliot.miranda at gmail.com>
wrote:

>
> Hi Javier,
>
> On Tue, Mar 21, 2017 at 6:34 AM, Javier Pimás <elpochodelagente at gmail.com>
> wrote:
>
>>
>> Wow! it is really encouraging to see that you kept the candle burning,
>> and the interest of the community. We have to integrate both what you and
>> we did into one.
>>
>> Our approach started very recently and for now has only been focused in
>> getting the VM compile and link with the upstream sources, to be able to
>> run with current versions of pharo, without touching upstream files.
>>  In case any modifications are needed they can either be asked to
>> integrate upstream o either be generated automatically against current
>> sources via scripts. I believe this is the right way to do it, otherwise
>> the code gets rotten really soon, and this is what we had started to do.
>>
>> I see that we both took the same direction about using musl. Using parts
>> of libc from system directories was a pain. We are able to cross-compile
>> from 64-bits systems: ubuntu and osx.
>>
>> I agree that having something like NativeBoost would be nice to be able
>> to code all things that require assembly, specially io. It isn't a huge
>> difference for now at it replaces a plugin that just executes in and out
>> x86 instructions, but it'd make a nice plus to have available
>>
>
> See the work Clément and I have done on inline primitives and Ronie
> Salgado's work on Lowcode.  Here we extend the byte code set with low-level
> in-line primitives, but they are still cross-platform.  These primitives
> are unsafe; they do no checking, and expect particular kinds of operands.
> The JIT translates them into the relevant machine instructions.
>

That may work if arm has in and out instructions as x86. But the thing is
that the kind of code involved is hyper architecture specific. For example
this is used to access keyboard and pic following protocols that I think
apply only to IBM/PC.


> Esteban: when you say "to make the memory executable" you forget this is
>> squeaknos :). I mean, maybe we only need the plugin to work in squeaknos
>> platform, not the others, would that make the task easier?
>>
>
> :-)
>
> Tim: this is already architecture specific code, which already exists but
>> at VM level; I would rather have it coded in Smalltalk.
>>
>
> Ronie's work is probably the most relevant.
>

We should have a look then.


>
>
>>
>> Eliot: does UFFI allow execution of arbitrary assembly?
>>
>
> No. But we have support for x86, x86_64 & ARM call-outs and callbacks.
>
>
> Can you talk about things like the implementation of page fault interrupt
> handlers, etc?
>

That was a nice thing we did with Guido. And regarding it there are some
modifications we noticed we'll have to do with current code, where we'll
need your help.

In x86 you have the IDT which is a table of interrupt descriptors,
basically the addresses of the handlers and some extra bits. Most of
SqueakNOS handlers are very similar: a piece of assembly code that saves
all registers, signals a smalltalk semaphore (from native world), restores
regs and quits. Actual handling of the interrupt is delayed: for each
interrupt there's a high priority smalltalk process blocked waiting on its
corresponding semaphore, so when reentering smalltalk world, the sleeping
process is quickly awoken and handles the interrupt.

In the case of page-faults, interrupt handling cannot be delayed (you
cannot return to the code that pagefaulted), so the handler saves vm status
and reenters the VM immediately to deal with the interrupt. To be able to
do so, VM status has to be saved, in order to restore it after the int has
been handled. This works basically because the code that causes page faults
is mostly controlled: pf are raised at smalltalk code, by hand (it'd
probably crash for example if the VM itself generated a page fault).

Status saving code was written by us by hand, maybe in the future this
could be reified in a method of the interpreter that does the job. Going
back to the thing that seems to have changed: vm status is stored in a
bunch of variables in interp.c, that are now declared as static. Probably
this was not the case before, and because of the static we cannot access it
from other files. We have to find a solution for that (for now it is
appending saving status funcs to interp.c).

I had forgotten how all this irq handling mechanism worked, it is nice to
have it back in my mindmap.

Cheers!


> Cheers!
>> Pocho
>>
>> On Mon, Mar 20, 2017 at 6:57 PM, tim Rowledge <tim at rowledge.org> wrote:
>>
>>>
>>>
>>> > On 20-03-2017, at 2:48 PM, Eliot Miranda <eliot.miranda at gmail.com>
>>> wrote:
>>> >
>>> >> Hi Jan,
>>> >>
>>> >> On Sun, Mar 19, 2017 at 1:46 PM, jan.struz <public+pharo at struz.cz>
>>> wrote:
>>> >> Hi Stef,
>>> >> what I want, is NativeBoost for Pharo 5+. Because we could do this:
>>> >>
>>> >
>>> > Can you not use the new UnifiedFFI which uses the ThreadedFFIPlugin at
>>> the bottom level?
>>> >
>>>
>>> Not to mention that native boost excludes ARM cpus. Which are the most
>>> numerous by quite a large factor...
>>>
>>> tim
>>> --
>>> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
>>> Klingon Code Warrior:- 2) "My program has just dumped Stova Core!"
>>>
>>>
>>>
>>
>>
>> --
>> Javier Pimás
>> Ciudad de Buenos Aires
>>
>>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>
>


-- 
Javier Pimás
Ciudad de Buenos Aires
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170322/30ec5be4/attachment.html>


More information about the Vm-dev mailing list