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

[Eliot Miranda]

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.

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.


>
> 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?

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170321/99f64224/attachment.html>