From: Nivedita P. <ni...@gm...> - 2009-01-21 17:49:08
|
Hello, I need to jump to a function _foo i.e JMP _foo instead of Call _foo I see JMP is always to a label within the same block But i need to jump to a different function. Please Help I am struck Thanks Nivedita |
From: Eliot M. <mo...@cs...> - 2009-01-21 18:03:30
|
Nivedita Puranik wrote: > Hello, > I need to jump to a function _foo i.e JMP _foo instead of Call _foo > I see JMP is always to a label within the same block > But i need to jump to a different function. Please Help I am struck Nivedita -- I told you that I believe you will have to create a new kind of instruction at the HIR level: a "jump to method" rather than a "call method". But perhaps Dave Grove or someone can offer more detailed guidance. (She's trying to do a more general form of tail call elimination.) Best wishes -- Eliot Moss |
From: Ian R. <ian...@ma...> - 2009-01-21 23:12:29
|
2009/1/21 Eliot Moss <mo...@cs...> > Nivedita Puranik wrote: > > Hello, > > I need to jump to a function _foo i.e JMP _foo instead of Call _foo > > I see JMP is always to a label within the same block > > But i need to jump to a different function. Please Help I am struck > > Nivedita -- I told you that I believe you will have to create a new kind > of instruction at the HIR level: a "jump to method" rather than a > "call method". But perhaps Dave Grove or someone can offer more detailed > guidance. > > (She's trying to do a more general form of tail call elimination.) > > Best wishes -- Eliot Moss > Hi Nivedita & Eliot, I'd suggest that you probably need to create a new form of MIR_Call operation that during calling convention expansion [1] can be turned into a jmp (just as a syscall will get flipped into a call on the way to the assembler driver you can flip your pseudo instruction into a jmp). I think you want to reconsider using jmp as apposed to call, Intel processors have a return stack buffer (RSB) [2] that is used to predict the return address of return instructions. By using a jmp instruction you will cause the RSB to miss. Such a miss may cause around a 10% slowdown - our switch instructions in old Jikes RVM's caused the RSB to miss and fixing this caused a 10% speedup on some DaCapo benchmarks (those that had switches of >8 elements in their critical path). Regards, Ian [1] http://jikesrvm.svn.sourceforge.net/viewvc/jikesrvm/rvmroot/trunk/rvm/src/org/jikesrvm/compilers/opt/regalloc/ia32/CallingConvention.java?revision=15220&view=markup [2] http://download.intel.com/design/processor/manuals/248966.pdf page 2-6 |
From: Ian R. <ian...@ma...> - 2009-01-22 00:50:51
|
2009/1/21 Ian Rogers <ian...@ma...> > 2009/1/21 Eliot Moss <mo...@cs...> > >> Nivedita Puranik wrote: >> > Hello, >> > I need to jump to a function _foo i.e JMP _foo instead of Call _foo >> > I see JMP is always to a label within the same block >> > But i need to jump to a different function. Please Help I am struck >> >> Nivedita -- I told you that I believe you will have to create a new kind >> of instruction at the HIR level: a "jump to method" rather than a >> "call method". But perhaps Dave Grove or someone can offer more detailed >> guidance. >> >> (She's trying to do a more general form of tail call elimination.) >> >> Best wishes -- Eliot Moss >> > > Hi Nivedita & Eliot, > > I'd suggest that you probably need to create a new form of MIR_Call > operation that during calling convention expansion [1] can be turned into a > jmp (just as a syscall will get flipped into a call on the way to the > assembler driver you can flip your pseudo instruction into a jmp). I think > you want to reconsider using jmp as apposed to call, Intel processors have a > return stack buffer (RSB) [2] that is used to predict the return address of > return instructions. By using a jmp instruction you will cause the RSB to > miss. Such a miss may cause around a 10% slowdown - our switch instructions > in old Jikes RVM's caused the RSB to miss and fixing this caused a 10% > speedup on some DaCapo benchmarks (those that had switches of >8 elements in > their critical path). > > Regards, > Ian > > [1] > http://jikesrvm.svn.sourceforge.net/viewvc/jikesrvm/rvmroot/trunk/rvm/src/org/jikesrvm/compilers/opt/regalloc/ia32/CallingConvention.java?revision=15220&view=markup > [2] http://download.intel.com/design/processor/manuals/248966.pdf page 2-6 > Ignore my comments on the RSB (it's far too late here), the number of calls and returns (and the sites) will correspond with tail call elimination, so the RSB will do its job well. Regards, Ian |
From: David P G. <gr...@us...> - 2009-01-22 15:06:43
|
Ian Rogers <ian...@ma...> wrote on 01/21/2009 07:50:43 PM: > Nivedita Puranik wrote: > > Hello, > > I need to jump to a function _foo i.e JMP _foo instead of Call _foo > > I see JMP is always to a label within the same block > > But i need to jump to a different function. Please Help I am struck > Nivedita -- I told you that I believe you will have to create a new kind > of instruction at the HIR level: a "jump to method" rather than a > "call method". But perhaps Dave Grove or someone can offer more detailed > guidance. > > (She's trying to do a more general form of tail call elimination.) > > Best wishes -- Eliot Moss > > Hi Nivedita & Eliot, > > I'd suggest that you probably need to create a new form of MIR_Call > operation that during calling convention expansion [1] can be turned > into a jmp (just as a syscall will get flipped into a call on the > way to the assembler driver you can flip your pseudo instruction > into a jmp). I think you want to reconsider using jmp as apposed to > call, Intel processors have a return stack buffer (RSB) [2] that is > used to predict the return address of return instructions. By using > a jmp instruction you will cause the RSB to miss. Such a miss may > cause around a 10% slowdown - our switch instructions in old Jikes > RVM's caused the RSB to miss and fixing this caused a 10% speedup on > some DaCapo benchmarks (those that had switches of >8 elements in > their critical path). This seems about right to me. You'll want to somehow mark the HIR/LIR instruction as a tail call (most likely by adding a tail call boolean to the MethodOperand object). When you get to calling convention expansion, this is where you'll want to do something different (use jmp instead of a call). You may need to do some work in the assemblers to teach it about this instruction. I think JMP is the right thing here (not call) because with a tail call you aren't going to be returning to the instruction after the JMP (that's the point). So you want to leave the RSB unchanged because when you eventually do a RET, it will be to the last place you did a CALL from not from the place you did the JMP from. --dave |
From: Nivedita P. <ni...@gm...> - 2009-01-23 15:29:17
|
Hello, I apologize if i am wrong but i am struck with the following But now i am trying to change the CALL to JMP using MIR_BRANCH.mutate I do the following in Calling convention only if its a tail call MIR_BRANCH.mutate(s,IA32_JMP,BranchOperand(s.getAddress())) How to get the address of the CALL might be BranchOperand is just a label. I get an error ********* START OF IR DUMP Verify: right before Final MIR Expansion: < SystemAppCL, LDev; >.Helper ()V FOR < SystemAppCL, LDev; >.Helper ()V -13 LABEL0 Frequency: 1.0 0 ia32_add ESP(I) AF CF OF PF SF ZF <-- -12 0 require_esp 0 0 require_esp 0 0 ia32_jmp <unused> 0 advise_esp 0 -1 bbend BB0 (ENTRY) Basic block BB0 (ENTRY) in: <none> normal out: EXIT1 exceptional out: <none> May throw uncaught exceptions, implicit edge to EXIT Instructions: -13: LABEL0 0: ia32_add ESP(I) AF CF OF PF SF ZF <-- -12 0: require_esp 0 0: require_esp 0 0: ia32_jmp <unused> 0: advise_esp 0 -1: bbend BB0 (ENTRY) Basic block EXIT1 in: BB0 (ENTRY) normal out: <none> exceptional out: <none> ********* END OF IR DUMP Verify: right before Final MIR Expansion: < SystemAppCL, LDev; >.Helper ()V FOR < SystemAppCL, LDev; >.Helper ()V VERIFY: right before Final MIR Expansion Unconditional branch ia32_jmp <unused> does not end its basic block BB0 (ENTRY) On Thu, Jan 22, 2009 at 10:05 AM, David P Grove <gr...@us...> wrote: > Ian Rogers <ian...@ma...> wrote on 01/21/2009 07:50:43 PM: > > > Nivedita Puranik wrote: > > > Hello, > > > I need to jump to a function _foo i.e JMP _foo instead of Call _foo > > > I see JMP is always to a label within the same block > > > But i need to jump to a different function. Please Help I am struck > > > Nivedita -- I told you that I believe you will have to create a new kind > > of instruction at the HIR level: a "jump to method" rather than a > > "call method". But perhaps Dave Grove or someone can offer more detailed > > guidance. > > > > (She's trying to do a more general form of tail call elimination.) > > > > Best wishes -- Eliot Moss > > > > Hi Nivedita & Eliot, > > > > I'd suggest that you probably need to create a new form of MIR_Call > > operation that during calling convention expansion [1] can be turned > > into a jmp (just as a syscall will get flipped into a call on the > > way to the assembler driver you can flip your pseudo instruction > > into a jmp). I think you want to reconsider using jmp as apposed to > > call, Intel processors have a return stack buffer (RSB) [2] that is > > used to predict the return address of return instructions. By using > > a jmp instruction you will cause the RSB to miss. Such a miss may > > cause around a 10% slowdown - our switch instructions in old Jikes > > RVM's caused the RSB to miss and fixing this caused a 10% speedup on > > some DaCapo benchmarks (those that had switches of >8 elements in > > their critical path). > > This seems about right to me. You'll want to somehow mark the HIR/LIR > instruction as a tail call (most likely by adding a tail call boolean to the > MethodOperand object). When you get to calling convention expansion, this > is where you'll want to do something different (use jmp instead of a call). > You may need to do some work in the assemblers to teach it about this > instruction. > > I think JMP is the right thing here (not call) because with a tail call you > aren't going to be returning to the instruction after the JMP (that's the > point). So you want to leave the RSB unchanged because when you eventually > do a RET, it will be to the last place you did a CALL from not from the > place you did the JMP from. > > --dave > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Jikesrvm-researchers mailing list > Jik...@li... > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers > > |
From: Nivedita P. <ni...@gm...> - 2009-01-25 04:49:13
|
As suggested i have made the changes in CallingConvention to flip the MIR_CALL instruction to a IA32_JMP only if its a TAIL CALL But the BranchOperand Target value of the IA_32 JMP should be the address to the compiled method ID which is not correct please help Actually We have the JTOC offset containing the address to the Method being called On setting that value to the BranchOperand it fails On Thu, Jan 22, 2009 at 10:05 AM, David P Grove <gr...@us...> wrote: > Ian Rogers <ian...@ma...> wrote on 01/21/2009 07:50:43 PM: > > > Nivedita Puranik wrote: > > > Hello, > > > I need to jump to a function _foo i.e JMP _foo instead of Call _foo > > > I see JMP is always to a label within the same block > > > But i need to jump to a different function. Please Help I am struck > > > Nivedita -- I told you that I believe you will have to create a new kind > > of instruction at the HIR level: a "jump to method" rather than a > > "call method". But perhaps Dave Grove or someone can offer more detailed > > guidance. > > > > (She's trying to do a more general form of tail call elimination.) > > > > Best wishes -- Eliot Moss > > > > Hi Nivedita & Eliot, > > > > I'd suggest that you probably need to create a new form of MIR_Call > > operation that during calling convention expansion [1] can be turned > > into a jmp (just as a syscall will get flipped into a call on the > > way to the assembler driver you can flip your pseudo instruction > > into a jmp). I think you want to reconsider using jmp as apposed to > > call, Intel processors have a return stack buffer (RSB) [2] that is > > used to predict the return address of return instructions. By using > > a jmp instruction you will cause the RSB to miss. Such a miss may > > cause around a 10% slowdown - our switch instructions in old Jikes > > RVM's caused the RSB to miss and fixing this caused a 10% speedup on > > some DaCapo benchmarks (those that had switches of >8 elements in > > their critical path). > > This seems about right to me. You'll want to somehow mark the HIR/LIR > instruction as a tail call (most likely by adding a tail call boolean to the > MethodOperand object). When you get to calling convention expansion, this > is where you'll want to do something different (use jmp instead of a call). > You may need to do some work in the assemblers to teach it about this > instruction. > > I think JMP is the right thing here (not call) because with a tail call you > aren't going to be returning to the instruction after the JMP (that's the > point). So you want to leave the RSB unchanged because when you eventually > do a RET, it will be to the last place you did a CALL from not from the > place you did the JMP from. > > --dave > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Jikesrvm-researchers mailing list > Jik...@li... > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers > > |
From: Nivedita P. <ni...@gm...> - 2009-01-25 14:32:42
|
Hello Please Respond > As suggested i have made the changes in CallingConvention to flip the > MIR_CALL instruction to a IA32_JMP only if its a TAIL CALL > But the BranchOperand Target value of the IA_32 JMP should be the address > to the compiled method ID which is not correct please help > Actually We have the JTOC offset containing the address to the Method being > called On setting that value to the BranchOperand it fails > > Dear Nivedita -- > > Someone else will have to answer about the exact place > to make the changes you're talking about. However, I think > that it has to do with either LIR->MIR, which is mediated > by BURS rules, or (maybe) LIR->assembler. This > does not apply to the Baseline compile actually, since > it does not do optimization at all. This happens somewhere > in the Opt compiler back-end. > > If you can ask your question clearly enough, Dave G or someone > can answer it. I think you are asking: > > "Where in the compiler should I look for the Java module(s) to > modify to add the translation of my new IR instruction to > assembly code?" > > A related question is: > > "Is translating this instruction more properly an LIR-to-MIR > step or an MIR-to-assembly code step?" > > Best wishes -- EM > > On Thu, Jan 22, 2009 at 10:05 AM, David P Grove <gr...@us...>wrote: > >> Ian Rogers <ian...@ma...> wrote on 01/21/2009 07:50:43 >> PM: >> >> > Nivedita Puranik wrote: >> > > Hello, >> > > I need to jump to a function _foo i.e JMP _foo instead of Call _foo >> > > I see JMP is always to a label within the same block >> > > But i need to jump to a different function. Please Help I am struck >> >> >> > Nivedita -- I told you that I believe you will have to create a new kind >> > of instruction at the HIR level: a "jump to method" rather than a >> > "call method". But perhaps Dave Grove or someone can offer more detailed >> > guidance. >> > >> > (She's trying to do a more general form of tail call elimination.) >> > >> > Best wishes -- Eliot Moss >> > >> > Hi Nivedita & Eliot, >> > >> > I'd suggest that you probably need to create a new form of MIR_Call >> > operation that during calling convention expansion [1] can be turned >> > into a jmp (just as a syscall will get flipped into a call on the >> > way to the assembler driver you can flip your pseudo instruction >> > into a jmp). I think you want to reconsider using jmp as apposed to >> > call, Intel processors have a return stack buffer (RSB) [2] that is >> > used to predict the return address of return instructions. By using >> > a jmp instruction you will cause the RSB to miss. Such a miss may >> > cause around a 10% slowdown - our switch instructions in old Jikes >> > RVM's caused the RSB to miss and fixing this caused a 10% speedup on >> > some DaCapo benchmarks (those that had switches of >8 elements in >> > their critical path). >> >> This seems about right to me. You'll want to somehow mark the HIR/LIR >> instruction as a tail call (most likely by adding a tail call boolean to the >> MethodOperand object). When you get to calling convention expansion, this >> is where you'll want to do something different (use jmp instead of a call). >> You may need to do some work in the assemblers to teach it about this >> instruction. >> >> I think JMP is the right thing here (not call) because with a tail call >> you aren't going to be returning to the instruction after the JMP (that's >> the point). So you want to leave the RSB unchanged because when you >> eventually do a RET, it will be to the last place you did a CALL from not >> from the place you did the JMP from. >> >> --dave >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by: >> SourcForge Community >> SourceForge wants to tell your story. >> http://p.sf.net/sfu/sf-spreadtheword >> _______________________________________________ >> Jikesrvm-researchers mailing list >> Jik...@li... >> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers >> >> > |
From: Nivedita P. <ni...@gm...> - 2009-01-27 17:20:18
|
Why is there difference in the address Difficult to understand the loadJTOC offset and copyD2U() EG call AF CF OF PF ZF ESP = Addr 0x00015e08, static"< SystemAppCL, LDev; >.one ()V", is the same call where the address changed after setAddress ia32_call AF CF OF PF ZF ESP = <0+1460232336>DW, static"< SystemAppCL, LDev; >.one ()V" ESP Please Help Nivedita |
From: Ian R. <ian...@ma...> - 2009-01-28 09:32:51
|
Hi Nivedita, 2009/1/27 Nivedita Puranik <ni...@gm...>: > Why is there difference in the address Difficult to understand the loadJTOC > offset and copyD2U() > > EG call AF CF OF PF ZF ESP = Addr 0x00015e08, static"< > SystemAppCL, LDev; >.one ()V", This is a HIR/LIR call that has information pertinent to it being a static call, so the offset into the JTOC. > is the same call where the address changed after setAddress > > ia32_call AF CF OF PF ZF ESP = <0+1460232336>DW, static"< > SystemAppCL, LDev; >.one ()V" ESP This is an actual Intel call instruction, as the JTOC address is a constant it has been folded into the instruction which means "call the routine at the address you load from 1460232336". There are other subtle differences in that the HIR/LIR call instruction is platform independent, the latter instruction is Intel specific and a different instruction (well more than 1) would be necessary on PowerPC. The types of the operands also vary. Regards, Ian > Please Help > Nivedita |
From: Nivedita P. <ni...@gm...> - 2009-02-02 15:28:59
|
Hi Ian, but if i jump to this address 1460232336. I get a negative mcoffset error. Thanks Nivedita ia32_call AF CF OF PF ZF ESP = <0+1460232336>DW, static"< SystemAppCL, LDev; >.one ()V" ESP On Wed, Jan 28, 2009 at 4:32 AM, Ian Rogers <ian...@ma...>wrote: > Hi Nivedita, > > 2009/1/27 Nivedita Puranik <ni...@gm...>: > > Why is there difference in the address Difficult to understand the > loadJTOC > > offset and copyD2U() > > > > EG call AF CF OF PF ZF ESP = Addr 0x00015e08, > static"< > > SystemAppCL, LDev; >.one ()V", > > > This is a HIR/LIR call that has information pertinent to it being a > static call, so the offset into the JTOC. > > > is the same call where the address changed after setAddress > > > > ia32_call AF CF OF PF ZF ESP = <0+1460232336>DW, static"< > > SystemAppCL, LDev; >.one ()V" ESP > > This is an actual Intel call instruction, as the JTOC address is a > constant it has been folded into the instruction which means "call the > routine at the address you load from 1460232336". There are other > subtle differences in that the HIR/LIR call instruction is platform > independent, the latter instruction is Intel specific and a different > instruction (well more than 1) would be necessary on PowerPC. The > types of the operands also vary. > > Regards, > Ian > > > Please Help > > Nivedita > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Jikesrvm-researchers mailing list > Jik...@li... > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers > |
From: Eliot M. <mo...@cs...> - 2009-01-23 15:39:14
|
Nivedita -- Just changing the call to a jmp is not enough, since the argument have to be in the right place on the stack, as well as the eventual return address, etc. This is a deeper code generation change that you will need to push through the back end .... EM |
From: Ian R. <ian...@ma...> - 2009-01-23 15:44:45
|
Hi Nivedita, the particular error is about the IR verifier expecting branches only to end basic blocks. You need to create a new pseudo operator that is an MIR_Call, you will need to modify the code in rvm/src-generated/opt-ir to create this new instruction. As we verify between all compiler phases you may need to swizzle your pseudo instruction into an actual jmp in the final assembler expansion. Regards, Ian 2009/1/23 Eliot Moss <mo...@cs...> > Nivedita -- Just changing the call to a jmp is not enough, since > the argument have to be in the right place on the stack, as well as > the eventual return address, etc. This is a deeper code generation > change that you will need to push through the back end .... EM > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Jikesrvm-researchers mailing list > Jik...@li... > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers > |
From: Eliot M. <mo...@cs...> - 2009-01-23 20:32:17
|
Ian Rogers wrote: > Hi Nivedita, > > the particular error is about the IR verifier expecting branches only to > end basic blocks. You need to create a new pseudo operator that is an > MIR_Call, you will need to modify the code in rvm/src-generated/opt-ir > to create this new instruction. As we verify between all compiler phases > you may need to swizzle your pseudo instruction into an actual jmp in > the final assembler expansion. Yes, but optimization phases need to be aware that it ends control flow within the method, so in that sense it is not like a call .... EM |
From: Nivedita P. <ni...@gm...> - 2009-01-24 21:13:45
|
Hello, I am able to add the pseudo instruction IA32_TAILCALL (changed operatorlist.dat operatornames and all that stuff) and able to replace CALL with IA32_TAILCALL in BURS_HELPERS But at the final stage in AssemblerBase i donot understand how should this be translated to a set of machine instructions Please Help and let me know if i am on right track Nivedita On Fri, Jan 23, 2009 at 3:32 PM, Eliot Moss <mo...@cs...> wrote: > Ian Rogers wrote: > > Hi Nivedita, > > > > the particular error is about the IR verifier expecting branches only to > > end basic blocks. You need to create a new pseudo operator that is an > > MIR_Call, you will need to modify the code in rvm/src-generated/opt-ir > > to create this new instruction. As we verify between all compiler phases > > you may need to swizzle your pseudo instruction into an actual jmp in > > the final assembler expansion. > > Yes, but optimization phases need to be aware that it ends control flow > within the method, so in that sense it is not like a call .... EM > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Jikesrvm-researchers mailing list > Jik...@li... > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers > |
From: Eliot M. <mo...@cs...> - 2009-01-24 22:32:45
|
Dear Nivedita -- I'll try to say this again -- 3rd or 4th time now! Suppose A is doing a tail-call to B, and A's caller is X. As part of this tail-call instruction you must: Get all the arguments to B into the right place in the frame, where B will expect them. More generally, you need to make the world look like X just called B. This means shuffling things around in the stack. In the Baseline compile it might go something like this: a) if the return address from A into X is not in the right slot, emit code to move it to the right one b) emit code to pop the arguments to B one at a time, and to store each one where it should go (i.e., replacing args to A) c) emit code to cut back the stack frame to where it would be on entry to B (may not always be necessary, i.e., it may already be the right size on some occasions) d) emit the jump to B The exact details depend on the exact calling conventions in ia32, which I am not familiar with. The Opt compiler would be conceptually similar. Here you can emit code that copies everything you need to fresh temporaries, and then emit code to store all those temporaries to the proper stack slots. The back-end of the compiler will take care of using registers as effectively as it can, etc. It may require more work to avoid loading and storing any arguments to B that are already in the right place. Also, in the opt compiler, if B has more args than A, talking about the argument slots beyond those for A might be tricky. I am hoping that Dave or someone can help fill in some of the details here, but my key point is that it is *not* just replacing a call with a jump, because of argument passing. That simple replacement applies only if A and B have no arguments. Best wishes -- EM |
From: Eliot M. <mo...@cs...> - 2009-02-02 15:49:39
|
Nivedita Puranik wrote: > Hi Ian, > but if i jump to this address 1460232336. > I get a negative mcoffset error. Just a guess, but since this is through the JTOC, it should probably be a jump *indirect*. That is, the JTOC entry contains the starting address of the method in question. I observe that there is no real why a tail call could not be dynamically dispatched, i.e., a virtual method call, in which case you will be fetching the target address from the object's class's method vector .... Best -- Eliot |
From: Nivedita P. <ni...@gm...> - 2009-02-05 00:13:03
|
Hello, I am JMP to the address which would be the same for CALL like emitJMP_Abs(addr) instead of emitCALL_Abs(addr) But i get this error getInstructionOffset: ip is not within compiled code for method supposed method is LDev;.Helper ()V code for this method starts at 0x6780958c and has last valid return address of 0x678095d9 The requested instruction address was 0x00000000 Unable to find compiled method corresponding to this return address Attempting to dump virtual machine state before exiting Does that mean the compiled code is not available???????????/ public final void emitJMP_Abs(Address dstDisp) { int miStart = mi; setMachineCodes(mi++, (byte) 0xFF); // System.out.println("Address="+ dstDisp.toString()); // "register 0x4" is really part of the JMP opcode emitAbsRegOperands(dstDisp, GPR.getForOpcode(0x4)); if (lister != null) lister.RA(miStart, "JMP", dstDisp); } public final void emitCALL_Abs(Address dstDisp) { int miStart = mi; setMachineCodes(mi++, (byte) 0xFF); // "register 0x2" is really part of the CALL opcode emitAbsRegOperands(dstDisp, GPR.getForOpcode(0x2)); if (lister != null) lister.RA(miStart, "CALL", dstDisp); } On Mon, Feb 2, 2009 at 10:49 AM, Eliot Moss <mo...@cs...> wrote: > Nivedita Puranik wrote: > > Hi Ian, > > but if i jump to this address 1460232336. > > I get a negative mcoffset error. > > Just a guess, but since this is through the JTOC, it > should probably be a jump *indirect*. That is, the > JTOC entry contains the starting address of the > method in question. > > I observe that there is no real why a tail call > could not be dynamically dispatched, i.e., a > virtual method call, in which case you will > be fetching the target address from the object's > class's method vector .... > > Best -- Eliot > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Jikesrvm-researchers mailing list > Jik...@li... > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers > |
From: Nivedita P. <ni...@gm...> - 2009-02-05 01:06:48
|
Hello, I amtrying to JMP to the address which would be the same for CALL like emitJMP_Abs(addr) instead of emitCALL_Abs(addr) Becuase in a normal it is called this way and the method is executed But i get this error when i JMP to the same location instead..... getInstructionOffset: ip is not within compiled code for method supposed method is LDev;.Helper ()V code for this method starts at 0x6780958c and has last valid return address of 0x678095d9 The requested instruction address was 0x00000000 Unable to find compiled method corresponding to this return address Attempting to dump virtual machine state before exiting Does that mean the compiled code is not available???????????/ public final void emitJMP_Abs(Address dstDisp) { int miStart = mi; setMachineCodes(mi++, (byte) 0xFF); // System.out.println("Address="+ dstDisp.toString()); // "register 0x4" is really part of the JMP opcode emitAbsRegOperands(dstDisp, GPR.getForOpcode(0x4)); if (lister != null) lister.RA(miStart, "JMP", dstDisp); } public final void emitCALL_Abs(Address dstDisp) { int miStart = mi; setMachineCodes(mi++, (byte) 0xFF); // "register 0x2" is really part of the CALL opcode emitAbsRegOperands(dstDisp, GPR.getForOpcode(0x2)); if (lister != null) lister.RA(miStart, "CALL", dstDisp); |
From: Ian R. <ian...@ma...> - 2009-02-05 08:53:29
|
Hi Nivedita, 2009/2/5 Nivedita Puranik <ni...@gm...>: > Hello, > I amtrying to JMP to the address which would be the same for CALL like > emitJMP_Abs(addr) > instead of > emitCALL_Abs(addr) > Becuase in a normal it is called this way and the method is executed > But i get this error when i JMP to the same location instead..... > > getInstructionOffset: ip is not within compiled code for method > supposed method is LDev;.Helper ()V > code for this method starts at 0x6780958c > and has last valid return address of 0x678095d9 > The requested instruction address was 0x00000000 > Unable to find compiled method corresponding to this return address > Attempting to dump virtual machine state before exiting > > Does that mean the compiled code is not available???????????/ I'm not sure what you mean. I would run the RVM using gdb, "rvm -gdb", and set a breakpoint at the start of the method that fails and step by instruction through it. The addresses of all methods in the boot image are in RVM.map. If your method isn't in the boot image you can use the OptTestHarness to compile it, which will give the address the method was placed. The error itself would imply you are jumping to a garbage address (0). The RVM tries to give you a stack trace but can't correspond a bytecode to the address 0 for the method at the top of the stack, Dev.Helper. Ian > public final void emitJMP_Abs(Address dstDisp) { > int miStart = mi; > setMachineCodes(mi++, (byte) 0xFF); > // System.out.println("Address="+ dstDisp.toString()); > // "register 0x4" is really part of the JMP opcode > emitAbsRegOperands(dstDisp, GPR.getForOpcode(0x4)); > if (lister != null) lister.RA(miStart, "JMP", dstDisp); > } > > public final void emitCALL_Abs(Address dstDisp) { > int miStart = mi; > setMachineCodes(mi++, (byte) 0xFF); > // "register 0x2" is really part of the CALL opcode > emitAbsRegOperands(dstDisp, GPR.getForOpcode(0x2)); > if (lister != null) lister.RA(miStart, "CALL", dstDisp); > ------------------------------------------------------------------------------ > Create and Deploy Rich Internet Apps outside the browser with > Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills and code > to > build responsive, highly engaging applications that combine the power of > local > resources and data with the reach of the web. Download the Adobe AIR SDK and > Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com > _______________________________________________ > Jikesrvm-researchers mailing list > Jik...@li... > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers > > |
From: Nivedita P. <ni...@gm...> - 2009-02-05 15:13:57
|
Basically what i want to know is If it works for emitCALL_Abs(addr) then jumping to the same absolute address should also be right i.e emitJMP_Abs(addr) I want to know is Is CALL Abs_address same as JMP Abs_address I know in CALL it pushes the stack and then jumps to the address But is there some funda like FAR JMP , i even tried changing the opcode to FAR JMP it did not work Thanks Nivedita On Thu, Feb 5, 2009 at 3:53 AM, Ian Rogers <ian...@ma...>wrote: > Hi Nivedita, > > 2009/2/5 Nivedita Puranik <ni...@gm...>: > > Hello, > > I amtrying to JMP to the address which would be the same for CALL like > > emitJMP_Abs(addr) > > instead of > > emitCALL_Abs(addr) > > Becuase in a normal it is called this way and the method is executed > > But i get this error when i JMP to the same location instead..... > > > > getInstructionOffset: ip is not within compiled code for method > > supposed method is LDev;.Helper ()V > > code for this method starts at 0x6780958c > > and has last valid return address of 0x678095d9 > > The requested instruction address was 0x00000000 > > Unable to find compiled method corresponding to this return address > > Attempting to dump virtual machine state before exiting > > > > Does that mean the compiled code is not available???????????/ > > I'm not sure what you mean. I would run the RVM using gdb, "rvm -gdb", > and set a breakpoint at the start of the method that fails and step by > instruction through it. The addresses of all methods in the boot image > are in RVM.map. If your method isn't in the boot image you can use the > OptTestHarness to compile it, which will give the address the method > was placed. > > The error itself would imply you are jumping to a garbage address (0). > The RVM tries to give you a stack trace but can't correspond a > bytecode to the address 0 for the method at the top of the stack, > Dev.Helper. > > Ian > > > public final void emitJMP_Abs(Address dstDisp) { > > int miStart = mi; > > setMachineCodes(mi++, (byte) 0xFF); > > // System.out.println("Address="+ dstDisp.toString()); > > // "register 0x4" is really part of the JMP opcode > > emitAbsRegOperands(dstDisp, GPR.getForOpcode(0x4)); > > if (lister != null) lister.RA(miStart, "JMP", dstDisp); > > } > > > > public final void emitCALL_Abs(Address dstDisp) { > > int miStart = mi; > > setMachineCodes(mi++, (byte) 0xFF); > > // "register 0x2" is really part of the CALL opcode > > emitAbsRegOperands(dstDisp, GPR.getForOpcode(0x2)); > > if (lister != null) lister.RA(miStart, "CALL", dstDisp); > > > ------------------------------------------------------------------------------ > > Create and Deploy Rich Internet Apps outside the browser with > > Adobe(R)AIR(TM) > > software. With Adobe AIR, Ajax developers can use existing skills and > code > > to > > build responsive, highly engaging applications that combine the power of > > local > > resources and data with the reach of the web. Download the Adobe AIR SDK > and > > Ajax docs to start building applications today- > http://p.sf.net/sfu/adobe-com > > _______________________________________________ > > Jikesrvm-researchers mailing list > > Jik...@li... > > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers > > > > > > > ------------------------------------------------------------------------------ > Create and Deploy Rich Internet Apps outside the browser with > Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills and code > to > build responsive, highly engaging applications that combine the power of > local > resources and data with the reach of the web. Download the Adobe AIR SDK > and > Ajax docs to start building applications today- > http://p.sf.net/sfu/adobe-com > _______________________________________________ > Jikesrvm-researchers mailing list > Jik...@li... > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers > |
From: Ian R. <ian...@ma...> - 2009-02-05 15:43:32
|
2009/2/5 Nivedita Puranik <ni...@gm...>: > Basically what i want to know is > If it works for emitCALL_Abs(addr) > then jumping to the same absolute address should also be right > i.e emitJMP_Abs(addr) > > I want to know is > Is > CALL Abs_address > same as > JMP Abs_address > > I know in CALL it pushes the stack and then jumps to the address > But is there some funda like FAR JMP , i even tried changing the opcode > to FAR JMP it did not work > Thanks > Nivedita CALL_Abs and JMP_Abs will transfer control to the instruction loaded from the Abs address. ie: emitJMP_Abs(Address.fromInt(0x1234)); will generate an instruction that will load the value at address 0x1234 and this value will be the address of the next instruction. Ian > On Thu, Feb 5, 2009 at 3:53 AM, Ian Rogers <ian...@ma...> > wrote: >> >> Hi Nivedita, >> >> 2009/2/5 Nivedita Puranik <ni...@gm...>: >> > Hello, >> > I amtrying to JMP to the address which would be the same for CALL like >> > emitJMP_Abs(addr) >> > instead of >> > emitCALL_Abs(addr) >> > Becuase in a normal it is called this way and the method is executed >> > But i get this error when i JMP to the same location instead..... >> > >> > getInstructionOffset: ip is not within compiled code for method >> > supposed method is LDev;.Helper ()V >> > code for this method starts at 0x6780958c >> > and has last valid return address of 0x678095d9 >> > The requested instruction address was 0x00000000 >> > Unable to find compiled method corresponding to this return address >> > Attempting to dump virtual machine state before exiting >> > >> > Does that mean the compiled code is not available???????????/ >> >> I'm not sure what you mean. I would run the RVM using gdb, "rvm -gdb", >> and set a breakpoint at the start of the method that fails and step by >> instruction through it. The addresses of all methods in the boot image >> are in RVM.map. If your method isn't in the boot image you can use the >> OptTestHarness to compile it, which will give the address the method >> was placed. >> >> The error itself would imply you are jumping to a garbage address (0). >> The RVM tries to give you a stack trace but can't correspond a >> bytecode to the address 0 for the method at the top of the stack, >> Dev.Helper. >> >> Ian >> >> > public final void emitJMP_Abs(Address dstDisp) { >> > int miStart = mi; >> > setMachineCodes(mi++, (byte) 0xFF); >> > // System.out.println("Address="+ dstDisp.toString()); >> > // "register 0x4" is really part of the JMP opcode >> > emitAbsRegOperands(dstDisp, GPR.getForOpcode(0x4)); >> > if (lister != null) lister.RA(miStart, "JMP", dstDisp); >> > } >> > >> > public final void emitCALL_Abs(Address dstDisp) { >> > int miStart = mi; >> > setMachineCodes(mi++, (byte) 0xFF); >> > // "register 0x2" is really part of the CALL opcode >> > emitAbsRegOperands(dstDisp, GPR.getForOpcode(0x2)); >> > if (lister != null) lister.RA(miStart, "CALL", dstDisp); >> > >> > ------------------------------------------------------------------------------ >> > Create and Deploy Rich Internet Apps outside the browser with >> > Adobe(R)AIR(TM) >> > software. With Adobe AIR, Ajax developers can use existing skills and >> > code >> > to >> > build responsive, highly engaging applications that combine the power of >> > local >> > resources and data with the reach of the web. Download the Adobe AIR SDK >> > and >> > Ajax docs to start building applications >> > today-http://p.sf.net/sfu/adobe-com >> > _______________________________________________ >> > Jikesrvm-researchers mailing list >> > Jik...@li... >> > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers >> > >> > >> >> >> ------------------------------------------------------------------------------ >> Create and Deploy Rich Internet Apps outside the browser with >> Adobe(R)AIR(TM) >> software. With Adobe AIR, Ajax developers can use existing skills and code >> to >> build responsive, highly engaging applications that combine the power of >> local >> resources and data with the reach of the web. Download the Adobe AIR SDK >> and >> Ajax docs to start building applications >> today-http://p.sf.net/sfu/adobe-com >> _______________________________________________ >> Jikesrvm-researchers mailing list >> Jik...@li... >> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers > > > ------------------------------------------------------------------------------ > Create and Deploy Rich Internet Apps outside the browser with > Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills and code > to > build responsive, highly engaging applications that combine the power of > local > resources and data with the reach of the web. Download the Adobe AIR SDK and > Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com > _______________________________________________ > Jikesrvm-researchers mailing list > Jik...@li... > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers > > |