Re: Porting to Darwin

Hi Steve,

The whole problem is that strongtalk implementation has too many
clever tricks, and the assembly code and C++ functions are really
interleaved. I tried to make a simple stub that align stack. But there
are too much code (assembly) that simply jump to C/C++ function
address, often indirectly.

Another problem is that the VM use system stack pointer (ESP) for VM
operand stack and even put bytecodes to system stack, making the
alignment hard to keep.

I fixed most of the call stubs including call_C many code generated in
C functions, yet it was not sufficient. I stopped while modifying
codes for bytecode primitives.

Yet I think we can make the 32 bit code work. What I'm saying is that
it's a long and hard work. Just fixing a few functions or making a
clever macro doesn't work. I tried.

Anyway, the reason I recommend using NASM is that it's less intuitive
to read and write asm code mapped to c functions, making it less
productive and error prone. And it has limitation on forward reference
to labels, if I recall correctly.

The runtime code generator is there already and it doesn't depend on
external assembler.
I'm not proposing to get rid of code generator written in C. What I'm
saying is that we'd better translate static assembly code which was
written in external MASM syntax to NASM, and keep static linking those
modules. For dynamically generated code we have no other way than
using code generator in C, and there is no reason to call external
assembler at run time.

But as you've done a lot of work already, it's up to you which way to
take.

Regards,
Hyungjip

PS> I want to send you my code so that you can take a look. But I'm
out of town now and will be for more than a month, that I can't access
the code at my home.
I'll resume working on Strongtalk VM as soon as possible. But it's not
before August.


On Jun 15, 7:05 am, talksmall <[email protected]> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---