Re: Porting to Darwin

Hyungjip Kim <[email protected]> Thu, 12 Jun 2008 00:53:36 -0700 (PDT)
Newsgroups gmane.comp.lang.smalltalk.strongtalk
Message-ID <0797030a-6796-450e-b07e-54f5a25fe382@z16g2000prn.googlegroups.com>
Hi Brian,

I worked on porting VM to Mac last summer, but stopped working on it
as I became rather busy.
It's not an easy job. I don't think the EBX is the problem, as it's
required only by position independent programs. But 16 byte alignment
is a big challenge.

MASM enter/leave would not help, methinks. As the assembly code uses
many tricks to switch between native code and VM emulation such as
jumps between asm functions and C++ functions and return with modified
stack, rather than regular call/return.

I think the best way is to port to 64 bit, as Mac OS X (darwin) uses
the same calling convention on 64 bit processors. But as my Mac was 32
bit at the time, I paused working on VM then got busy. Now I bought
myself a new 64 bit Intel Mac and I want to resume working on porting
to Mac / 64 bit ASAP, but not sure when it will be.

FYI, I think Apple chose 16 byte alignment so that they can utilize
SSE for floating point. As SSE requires 16 byte alignment for fp load/
store, it's inevitable. As all Intel Macs from Apple is SSE capable I
think it's good choice for them.

One more comment.
When I tried to port the ASM codes, I chose to use NASM which is free
and pre-installed with Mac dev tools. NASM is not fully MASM
compatible but much better than unix style asm. The last time I
checked, the linux port was changing all asm code to c++ code, which I
think is much harder to understand and maintain, and would be very
hard to port to 64 bit.
I think porting all asm codes to nasm should be the first step, and I
was in the middle of the job.
If anyone is interested in using NASM code, I'll try my best to finish
it (on a 32 bit linux first so that I can be sure it works fine).

Hyungjip Kim

On Jun 9, 2:19 pm, talksmall <[email protected]> wrote:
> Hi Brian,
> If you are pushing ebx in MacroAssembler::enter() this will very
> likely cause problems. When the VM starts executing Smalltalk code
> (either native nmethod code or interpreted code) is starts by calling
> the StubRoutines call delta function generated in
> StubRoutines::generate_call_delta(). This starts by calling masm->enter() and then pushes the frame pointers from the last delta (ie.
>
> Smalltalk) frame that it was executing in the current process. If you
> have changed masm->enter() to push ebx then these pointers will not be
> in the expected locations. Additionally, you will be pushing ebx for
> every delta method invocation which is almost certainly unnecessary.
>
> A better approach would be to preserve ebx after the other registers
> in the generated call_delta and restore it in the companion
> _return_from_delta the code for which is generated by the same
> generate_call_delta method. I have patched the generation code to do
> this. I was going to attach it to this message, but it seems Google
> doesn't want to let me, so I am including the contents of the patch
> (it's quite small) at the end of this message. I applied this locally
> within my Windows environment and everything continues to work. Let me
> know if you have any luck with this.
>
> BTW the reason that the easyunit tests pass is that none of them
> execute any Smalltalk code. At the moment, they test very specific
> behaviours within the VM itself. Over time I would expect us to expand
> the coverage, possibly including the execution of Smalltalk code, but
> we are not there yet.
>
> From the stack trace I see that you have created a new os_ module for
> darwin. You should make sure that the os::platform_class_name() still
> returns "UnixPlatform". This is used in the startup code to specify
> the platform class to bind to the global "Platform" in the system
> dictionary. This acts as a hook for all platform-specific code in the
> image (well it will do in the future, for now it just hooks in the
> file access code). You will need to be using libc 6 or have a link
> libc.so.6 that points to your libc.so, which cannot be a linker script
> (as it sometimes is in linux).
>
> Regards, Steve
>
> Patch contents below. Beware of line wrapping.
>
> Index: stubRoutines.cpp
> ===================================================================
> --- stubRoutines.cpp    (revision 139)
> +++ stubRoutines.cpp    (working copy)
> @@ -823,6 +823,7 @@
>
>    masm->pushl(edi); // save registers for C calling convetion
>    masm->pushl(esi);
> +  masm->pushl(ebx);
>
>    // reset last Delta frame
>    masm->reset_last_Delta_frame();
> @@ -862,7 +863,8 @@
>    masm->movl(Address((int)&have_nlr_through_C,
> relocInfo::external_word_type), 0);
>
>   masm->bind(_return);
> -  masm->leal(esp, Address(ebp, -4*oopSize));
> +  masm->leal(esp, Address(ebp, -5*oopSize));
> +  masm->popl(ebx);
>    masm->popl(esi);  // restore registers for C calling convetion
>    masm->popl(edi);
>    masm->popl(Address((int)&last_Delta_sp,
> relocInfo::external_word_type)); // reset _last_Delta_sp
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Strongtalk-general" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [email protected]
For more options, visit this group at http://groups.google.com/group/strongtalk-general?hl=en
-~----------~----~----~----~------~----~------~--~---