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

Ben Coman btc at openinworld.com
Tue Mar 21 23:58:53 UTC 2017


On Wed, Mar 22, 2017 at 7:28 AM, 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.
>
>> 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.

For easy reference...
http://www.esug.org/data/ESUG2016/IWST/Papers/IWST_2016_paper_16.pdf
https://github.com/OpenSmalltalk/opensmalltalk-vm/search?p=1&q=lowcode&type=Commits&utf8=%E2%9C%93

build.linux32x86/
  + pharo.stack.spur.lowcode
  + pharo.cog.spur.lowcode

cheers -ben


More information about the Vm-dev mailing list