Re: Porting to Darwin

Hi Hyungjip (or should that be "Hi Kim", please pardon my ignorance!),

On Jun 12, 8:53 am, Hyungjip Kim <[email protected]> wrote:
> 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.

Maybe, maybe not. I believe that the 16-byte alignment requirement is
a requirement of the C ABI, so it should only be necessary in order to
call C/C++ code.

Calls within the VM to non-C/C++ code whilst executing interpreted
code or native nmethod code should not need to be 16-byte aligned.
Calls from interpreter's assembler code to C/C++ should go via the
InterpreterGenerator's call_C function (more accurately call_C
generates assembler instructions for calling C code) which in turn
calls MacroAssembler::call_C. Typically this saves the last delta
frame pointer and sets up an inline cache. It could do more, such as
aligning the stack frame for a C call. Most (but sadly not all) such
calls are parameterless, which simplifies things. Where parameters are
passed to C code (such as in the compiled IC lookups) the calling code
could be modified to ensure 16-byte frame alignment (eg. in
StubRoutines::generate_ic_lookup() or
PrimitivesGenerator::allocateContext_var()).

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

Generally speaking such stack manipulation is in the context of delta
(ie. Smalltalk) frames called from other delta frames, or C functions
manipulating the contents of delta frames that invoked them. The delta
frames themselves are linked together by framepointers, even to the
extent that new calls to delta methods from C/C++ code are linked to
the last delta frame on the stack prior to the call to C/C++ code. I
think that the main tricky case is NLRs that fall through the stack
and hit C/C++ frames (or, more generally non-delta frames). In this
case the code sets the flag have_nlr_through_C and returns to the
calling function. Typically the C/C++ code will return to the prior
delta frame, cleaning up as it goes.

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

I think porting to 64-bit is actually quite a bit bigger job. It is
not just a question of changing oopSize and you're done ;) (I know you
know that!) All of the compiler and assembler code would need to be
modified to use 64 bit registers and instructions.

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

But nevertheless essential, since the code generator uses the macro
assembler for all of its generated code.

> 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).
>

The reason for porting the assembler routines to the built-in macro
assembler was partially to unify the assembler code in the VM. Short
of linking in an assembler into the Strongtalk VM we cannot get rid of
the existing macro assembler that is used by the code generator, and
that would create all sorts of complications (not least license
complications) and quite probably make the code generation slower.
Rather than have four languages to code in - Smalltalk, C/C++, the
built in macro assember and NASM(or TASM or some other assembler
variant) - using the built-in macro assembler to generate the stub and
interpreter routines allows us to reduce this to three.

Regards, Steve
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---