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