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 <zherc...@inf.u-szeged.hu> wrote: > >> From: Zoltan Herczeg <zherc...@inf.u-szeged.hu> >> Subject: Re: [webkit-dev] want to port JIT to MIPS - stack/code segment >> alignment >> To: webkit-dev@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 <last...@yahoo.com> >> wrote: >> > >> >> From: x yz <last...@yahoo.com> >> >> Subject: Re: [webkit-dev] want to port JIT to MIPS >> >> To: "WebKit Development" >> <webkit-dev@lists.webkit.org>, "Gavin >> >> Barraclough" <barraclo...@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 >> >> <barraclo...@apple.com> wrote: >> >> >> >> > From: Gavin Barraclough >> <barraclo...@apple.com> >> >> > Subject: Re: [webkit-dev] want to port JIT to >> MIPS >> >> > To: "WebKit Development" >> >> <webkit-dev@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 >> >> <last...@yahoo.com> >> >> > wrote: >> >> > > >> >> > >> From: x yz <last...@yahoo.com> >> >> > >> Subject: Re: [webkit-dev] want to >> port JIT to >> >> MIPS >> >> > - when WREC/JIT enabled? >> >> > >> To: "Gavin Barraclough" >> >> > <barraclo...@apple.com> >> >> > >> Cc: "WebKit Development" >> >> > <webkit-dev@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 >> >> > >> <barraclo...@apple.com> wrote: >> >> > >> >> >> > >>> From: Gavin Barraclough >> >> > <barraclo...@apple.com> >> >> > >>> Subject: Re: [webkit-dev] want >> to port >> >> JIT to >> >> > MIPS - >> >> > >> using X86::ecx as base >> >> > >>> To: last...@yahoo.com >> >> > >>> Cc: "WebKit >> Development" >> >> > >> <webkit-dev@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@lists.webkit.org >> >> > >> >> >> > >> >> >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> >> > > >> >> > > >> >> > > >> >> > >> >> > >> _______________________________________________ >> >> > webkit-dev mailing list >> >> > webkit-dev@lists.webkit.org >> >> > >> >> >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> >> >> >> >> >> >> >> _______________________________________________ >> >> webkit-dev mailing list >> >> webkit-dev@lists.webkit.org >> >> >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> > >> > >> > >> > _______________________________________________ >> > webkit-dev mailing list >> > webkit-dev@lists.webkit.org >> > >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> > >> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > > > _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev