Cog+NativeBoost @ Mac OS

Hello,

since recently i got access to macs, i were finally able to add NB
support for Mac OS.
I built the Cog VM with NativeBoost plugin , which you can download at
NativeBoost project page [1].

At image side you just load NativeBoost-Installer package
and then evaluate:

NBInstaller install.


Should i also build Squeak VM with NB plugin, or i could stick with Cog? :)

[1] http://code.google.com/p/nativeboost/downloads/list

--
Best regards,
Igor Stasenko AKA sig.

On Thu, 9 Dec 2010, Igor Stasenko wrote:

What about adding NativeBoost to the official VMs? There could be a
command line option to enable/disable it. What do you think?


Levente

>
> [1] http://code.google.com/p/nativeboost/downloads/list
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>

On 9 December 2010 15:54, Levente Uzonyi <[hidden email]> wrote:
i'm not opposed to this.

If you remember , i proposed to do this for FFI (keep it as builtin,
and enable either via command-line or via .ini file).
That is fairly possible.


> Levente

--
Best regards,
Igor Stasenko AKA sig.

Hi Igor,

On 9 December 2010 14:47, Igor Stasenko <[hidden email]> wrote:
> NBInstaller install.

wonderful, thank you *very* much.

I installed the examples (which appear to be working) and tests as
well, but the tests crash the VM. I have not yet tried to nail the
problem down; is this expected behaviour on the Mac?

Best,
thanks again,

Michael

Hi Igor,

here are some details.

On 9 December 2010 16:29, Michael Haupt <[hidden email]> wrote:
> I installed the examples (which appear to be working) and tests as
> well, but the tests crash the VM. I have not yet tried to nail the
> problem down; is this expected behaviour on the Mac?

most tests are green, but there are some issues:

1. NBUnixHeapManagerTests - 2 errors ("unable to map to virtual memory")
2. NBCallbackTests - assertion failure in NBInterpreterProxy >> #callInterpreter

I installed NB in a clean up-to-date Squeak trunk image and use the
Cog/NB VM from the NB Google code page.

Best,

Michael

On 9 December 2010 17:04, Michael Haupt <[hidden email]> wrote:
yeah, because it is for unix, not mac, but test not aware of it :)
Mac memory manager (NBMacExternalHeapManager) works ok, because it is
involved in a bootstrapping,
and you won't be able to run almost anything without successful bootstrap.
I have to disable this test , or better use an appropriate heap
manager for testing depending on platform.

> 2. NBCallbackTests - assertion failure in NBInterpreterProxy >> #callInterpreter
>

Yeah, callbacks not ready for Cog. I implemented necessary stuff, but
haven't time
to test it. So, don't use callbacks.
Also, Eliot made something cool with FFI , we yet have to see it, and
basicly i think
i will wait till release of it, so i can play more nicely with it than now.


Also, i haven't time to check all image-side code for compatibility with Mac.
I even didn't tried to do any external library call, i just tested
that assembler + interpreterProxy calls working ok.

Currently the Mac NB code using mostly the linux code, and sure thing
it could be different in some places specific to mac.

> I installed NB in a clean up-to-date Squeak trunk image and use the
> Cog/NB VM from the NB Google code page.
>


> Best,
>
> Michael
>
>



--
Best regards,
Igor Stasenko AKA sig.

Hi Igor,

OK, so those are "expected failures". :-)

On 9 December 2010 19:31, Igor Stasenko <[hidden email]> wrote:
> Currently the Mac NB code using mostly the linux code, and sure thing
> it could be different in some places specific to mac.

Are there any larger bodies of example code that could be used to
identify those places?

Best,

Michael

On 10 December 2010 11:44, Michael Haupt <[hidden email]> wrote:
There is no any 'large bodies of code', because all is dead simple. :)

For most ffi calls, a basic thing you need is to retrieve a function
pointer, like:

NativeBoost loadSymbol: 'gzopen' fromModule: 'libz'

and it doesn't works,
crashing with “EXC_BAD_ACCESS”  exception
somewhere in
misaligned_stack_error_

which gives a clue, why i got issues with pow() function before..
mac libs seems don't like misaligned stacks.. so i need to figure out
how to fix that
and align stack pages between the calls properly.
Strange that i met that only on Mac platform, and not before.
Maybe it because mac libs code extensively using MMX registers, which require
to use a properly aligned pointers when you loading the values in them.


> Best,
>
> Michael
>
>



--
Best regards,
Igor Stasenko AKA sig.

Yeah, i just found post which confirms my guess :)

http://blogs.embarcadero.com/eboling/2009/05/20/5607

<<
In the Mac OS X ABI Function Call Guide there is an innocent little
sentence:  "The stack is 16-byte aligned at the point of function
calls."  We’ve not been able to find out why this is required for the
IA-32 environment, but they really mean it, and there are deep
implications.
>>

how nice of them, isn't?  :))

--
Best regards,
Igor Stasenko AKA sig.

Hi Igor,

On 10 December 2010 14:36, Igor Stasenko <[hidden email]> wrote:
> how nice of them, isn't?  :))

at least it's documented. Not justified, but documented. Heh. :-)

Best,

Michael

On 10 December 2010 14:47, Michael Haupt <[hidden email]> wrote:
> Hi Igor,
>
> On 10 December 2010 14:36, Igor Stasenko <[hidden email]> wrote:
>> how nice of them, isn't?  :))
>
> at least it's documented. Not justified, but documented. Heh. :-)
>

well, it is relatively easy to watch for stack alignment in automatic
generated code.
but in manually crafted code this is not so nice..
okay, i can add some helpers so you can code something like:

gen alignStackBeforeCall: [
  ...
   push x;
   push y;
   ...
].
 do  call..

it's smalltalk, and we could handle such idiosyncrasy with ease :)

> Best,
>
> Michael
>
>



--
Best regards,
Igor Stasenko AKA sig.

Oh, yes in fact 5? years back I changed the FFI call for this because the Sophie team make a QuickTime FFI call and it was curtains....  Until I too read that "innocent little note".

On 10 December 2010 20:31, John M McIntosh
<[hidden email]> wrote:
> Oh, yes in fact 5? years back I changed the FFI call for this because the
> Sophie team make a QuickTime FFI call and it was curtains....  Until I too
> read that "innocent little note".
> In fact it's even worst than you can imagine since some bright software
> engineer said. Oh if the stack is 16 bytes aligned and well we've only 12
> bytes here, well hah I'll be clever and use that 4 bytes of padding for
> working storage...  Unfortunately that just happens to be some Squeak VM
> local var, but no matter I'm sure the VM will crash *later*....
>

Thanks, Eliot and John for paying attention to my troubles. :)

Yeah.. it is never too late to learn. Good that i found it relatively
quickly, because i was totally unaware of this innocent little thing.

--
Best regards,
Igor Stasenko AKA sig.