[webkit-dev] want to port JIT to MIPS - stack/code segment alignment

[Zoltan Herczeg]

Hi,

in ARM, we have a rule set called EABI (Embedded Application Binary
Interface). It says the stack must always be word aligned, and must be 2
words (8 bytes) aligned if you call other functions. The WebKit
interpreter callbacks returns either a single pointer (sometimes an int
contains a boolean value) or double pointers. These return values can be
passed through registers, no need to pre-allocate stack space for them.
The functions generated by g++ are also EABI compilant, so we don't need
worry about the stack at all.

I think AssemblerBuffer is only temporary hold the generated machine
instructions. When the compilation phase is done, you need to call
AssemblerBuffer::executableCopy, which allocates a new executable memory
space and that space is aligned by ExecutableAllocator.

Cheers,
Zoltan

> Zoltan,
> thanks a lot! yeah the issue is just JIT related.
> Do I need to take care of stack in JIT code, say before emit asm call I
> align the stack? I guess no need because Mips always aligned to 32bits,
> and the only double functions in webkit return result in registers not
> memory.
> For AssemblerBuffer.h I think it is different because the initial 256bytes
> buffer may be not aligned to 32bit. I'll add __attribute__ ((aligned (4)))
> or 8.
> rgds
> joe
>
>
> --- On Fri, 2/27/09, Zoltan Herczeg <zherczeg at inf.u-szeged.hu> wrote:
>
>> From: Zoltan Herczeg <zherczeg at inf.u-szeged.hu>
>> Subject: Re: [webkit-dev] want to port JIT to MIPS - stack/code segment
>> alignment
>> To: webkit-dev at lists.webkit.org
>> Date: Friday, February 27, 2009, 6:16 AM
>> Hi,
>>
>> I am not sure I understand your questions. The code blocks
>> are allocated
>> by mmap() or VirtualAlloc(), thus they are aligned to 4K.
>> Smaller chunks
>> are aligned by roundUpAllocationSize() function. Now the
>> alignemt is
>> sizeof(void*) in both x86 and ARM. See
>> ExecutableAllocator.h
>>
>> The current jit implementations don't store temporary
>> variables on the
>> stack, they allocate a fixed size buffer after the entry,
>> and only free
>> that when you leave the jit. This approach is much easier
>> than keep
>> tracking of the stack.
>>
>> Cheers,
>> Zoltan
>>
>> > gcc handles it well for X86. now on Mips I need to do
>> followings right?
>> > 1. make sure (re)allocated code buffer aligned to
>> 64bits and gcc malloc()
>> > only guarantee 32bits
>> > 2. before any call instruction in JIT code, make sure
>> stack is aligned to
>> > 64bit also.
>> > PPC no JIT thus no problem right?
>> > rgds
>> > joe
>> >
>> >
>> > --- On Sun, 2/22/09, x yz <lastguy at yahoo.com>
>> wrote:
>> >
>> >> From: x yz <lastguy at yahoo.com>
>> >> Subject: Re: [webkit-dev] want to port JIT to MIPS
>> >> To: "WebKit Development"
>> <webkit-dev at lists.webkit.org>, "Gavin
>> >> Barraclough" <barraclough at apple.com>
>> >> Date: Sunday, February 22, 2009, 4:34 PM
>> >> Thanks a lot otherwise I have misunderstanding.
>> Yes I'll
>> >> do wrec first. I just want to clean up possible
>> blocking
>> >> issues.
>> >>
>> >> I see wrec uses regparm(3) and jit always use
>> fastcall for
>> >> X86?
>> >> In JIT.cpp ctiTrampoline put CallFrame in edi, but
>> how
>> >> about other arguments - where are they be
>> fetched/poped from
>> >> stack?
>> >>
>> >> when deal with caller/callee saved regs, gcc MIPS
>> just
>> >> preserves them when necesasary. The problem is
>> after JIT
>> >> used gcc may not have enough knowledge on
>> >> "necessary", do we have a way to force
>> gcc always
>> >> preserve
>> >> them?
>> >>
>> >> how to identify a patch
>> (patchimm/patchptr/patchaddr)
>> >> relates to a data field in an instruction or
>> relates to an
>> >> element in a data array? In Mips the former means
>> the 32bit
>> >> needs to be separated into two 16bits and patched
>> into two
>> >> instructions. But if a 32bit is a pointer in a
>> pointer
>> >> array, we can save it directly.
>> >>
>> >> rgds
>> >> joe
>> >>
>> >>
>> >> --- On Fri, 2/20/09, Gavin Barraclough
>> >> <barraclough at apple.com> wrote:
>> >>
>> >> > From: Gavin Barraclough
>> <barraclough at apple.com>
>> >> > Subject: Re: [webkit-dev] want to port JIT to
>> MIPS
>> >> > To: "WebKit Development"
>> >> <webkit-dev at lists.webkit.org>
>> >> > Date: Friday, February 20, 2009, 2:01 PM
>> >> > On Feb 19, 2009, at 8:27 PM, x yz wrote:
>> >> >
>> >> > > I'd appreaciate your help to clarify
>> the
>> >> problem I
>> >> > faced:
>> >> > >
>> >> > > 1.In JIT.cpp I roughly understand
>> ctiTrampoline()
>> >> > except for sp-0x1C, I guess the 1C includes 6
>> argument
>> >> yet
>> >> > the 7th or 1st may be the hidden C++ pointer?
>> And the
>> >> > reserved 1C stack space seems not used? why
>> esi is
>> >> forced to
>> >> > be 512 rather than use input argument?
>> >> >
>> >> > The JIT allocates a fixed frame on the stack
>> which is
>> >> used
>> >> > to pass arguments into stub functions.  The
>> 0x1C
>> >> contains a
>> >> > spare word or two to maintain stack
>> alignment.  %esi
>> >> is used
>> >> > in the timeout check mechanism.
>> >> >
>> >> > > 2.How to understand the stack balance in
>> >> > ctiVMThrowTrampoline()? why after calling we
>> still add
>> >> 1C
>> >> > w/o sub 1C before calling? where comes
>> >> > _ZN3JSC11Interpreter12cti_vm_throwEPPv and
>> how do I
>> >> know
>> >> > which name for Mips? does this one relates to
>> variable
>> >> > argument function call?
>> >> >
>> >> > ctiVMThrowTrampoline is never called as a
>> function (it
>> >> is
>> >> > declared as a function only to provide a
>> symbol that
>> >> can be
>> >> > manipulated from C code).
>> ctiVMThrowTrampoline is
>> >> used in
>> >> > returning back from JIT generated code, in
>> the case of
>> >> an
>> >> > exception.
>> >> >
>> >> > > 3.I know how to handle jump in Mips, but
>> not sure
>> >> > how/when to handle
>> patchAddress/patchImm/patchPointer
>> >> > because I'm not sure the instructions
>> related. I
>> >> guess
>> >> > all patches are for last 32bit IMM field of
>> >> instructions.
>> >> > > Mips can't load 32bit in one
>> instruction,
>> >> thus I
>> >> > need to know the instruction before I can
>> patch/add in
>> >> the
>> >> > 32bit data.
>> >> > >
>> >> > > 4.I'm kind of want no asm code
>> outside
>> >> > <assembler> folder, any plan for that?
>> >> >
>> >> > No.  The assembler is intended to be
>> independent of
>> >> > JavaScript types - it's just an
>> assembler.  The
>> >> asm
>> >> > trampolines are specific to the JIT.  It is
>> currently
>> >> the
>> >> > intention that architecture specific parts of
>> the JIT
>> >> > implementation will remain in the jit folder.
>> >> >
>> >> > I'd suggest that in attempting to port
>> the jit,
>> >> WREC
>> >> > would be a good place to start.
>> >> >
>> >> > cheers,
>> >> > G.
>> >> >
>> >> > >
>> >> > > rgds
>> >> > > joe
>> >> > >
>> >> > > --- On Mon, 2/16/09, x yz
>> >> <lastguy at yahoo.com>
>> >> > wrote:
>> >> > >
>> >> > >> From: x yz <lastguy at yahoo.com>
>> >> > >> Subject: Re: [webkit-dev] want to
>> port JIT to
>> >> MIPS
>> >> > - when WREC/JIT enabled?
>> >> > >> To: "Gavin Barraclough"
>> >> > <barraclough at apple.com>
>> >> > >> Cc: "WebKit Development"
>> >> > <webkit-dev at lists.webkit.org>
>> >> > >> Date: Monday, February 16, 2009,
>> 5:25 AM
>> >> > >> Hi,
>> >> > >> from paltform.h it is enabled only
>> on X86
>> >> MAC/WIN;
>> >> > from
>> >> > >> javaScriptCore.pri it is also
>> enabled for
>> >> > (QT_ARCH,i386).
>> >> > >> But, from config.log I see them are
>> enabled!
>> >> > >>
>> >> > >> how can I run WREC/JIT test so I can
>> trace in
>> >> X86
>> >> > asm coce
>> >> > >> generated?
>> >> > >> thanks a lot.
>> >> > >> joe
>> >> > >>
>> >> > >>
>> >> > >>
>> >> > >> --- On Sat, 2/7/09, Gavin
>> Barraclough
>> >> > >> <barraclough at apple.com> wrote:
>> >> > >>
>> >> > >>> From: Gavin Barraclough
>> >> > <barraclough at apple.com>
>> >> > >>> Subject: Re: [webkit-dev] want
>> to port
>> >> JIT to
>> >> > MIPS -
>> >> > >> using X86::ecx as base
>> >> > >>> To: lastguy at yahoo.com
>> >> > >>> Cc: "WebKit
>> Development"
>> >> > >> <webkit-dev at lists.webkit.org>
>> >> > >>> Date: Saturday, February 7,
>> 2009, 7:08 AM
>> >> > >>> On Feb 6, 2009, at 2:52 PM, x yz
>> wrote:
>> >> > >>>
>> >> > >>>> 1.what's the meaning of
>> >> > ALTERNATE_JSIMMEDIATE
>> >> > >> and
>> >> > >>> slow case?
>> >> > >>>
>> >> > >>> On x86-64 we use a different
>> >> implementation of
>> >> > the
>> >> > >> class
>> >> > >>> JSImmediate.  See JSImmediate.h.
>> >> > >>> Re 'slow case', in the
>> JIT code
>> >> > generation is
>> >> > >>> performed as two passes over the
>> bytecode
>> >> –
>> >> > see
>> >> > >>> JIT::privateCompileMainPass and
>> >> > >>> JIT::privateCompileSlowCases.
>> >> > >>>
>> >> > >>>> 2.how come the following
>> code can use
>> >> ECX
>> >> > as base
>> >> > >>> register?
>> >> > >>>> load32(Address(X86::ecx,
>> >> > FIELD_OFFSET(Structure,
>> >> > >>> m_typeInfo.m_flags)), X86::ecx);
>> >> > >>>> if the X86::ecx just means
>> its value
>> >> 1 in
>> >> > ModR/M,
>> >> > >> does
>> >> > >>> it means [BX+DI]?
>> >> > >>>
>> >> > >>> I think you're looking at
>> the old
>> >> 16-bit
>> >> > >> addressing
>> >> > >>> mode tables; 32/64-bit x86 can
>> happily
>> >> encode
>> >> > ecx as a
>> >> > >> base
>> >> > >>> register.  If you're looking
>> at the
>> >> Intel
>> >> > IA-32
>> >> > >> manual
>> >> > >>> volume 2, see table 2-2 on the
>> next page.
>> >> > >>>
>> >> > >>>> 3. can anybody help me on my
>> previous
>> >> > questions?
>> >> > >> does
>> >> > >>> JIT support floating point?
>> >> > >>>
>> >> > >>> Yes, some.  See
>> JITArithmetic.cpp.
>> >> > >>>
>> >> > >>> cheers,
>> >> > >>> G.
>> >> > >>
>> >> > >>
>> >> > >>
>> >> > >>
>> >> _______________________________________________
>> >> > >> webkit-dev mailing list
>> >> > >> webkit-dev at lists.webkit.org
>> >> > >>
>> >> >
>> >>
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> >> > >
>> >> > >
>> >> > >
>> >> >
>> >> >
>> _______________________________________________
>> >> > webkit-dev mailing list
>> >> > webkit-dev at lists.webkit.org
>> >> >
>> >>
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> webkit-dev mailing list
>> >> webkit-dev at lists.webkit.org
>> >>
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> >
>> >
>> >
>> > _______________________________________________
>> > webkit-dev mailing list
>> > webkit-dev at lists.webkit.org
>> >
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> >
>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>
>