On 7/19/12 2:52 PM, Xin Tong wrote:> On Thu, Jul 19, 2012 at 2:28 PM, John Criswell <criswell at illinois.edu> wrote: >> On 7/19/12 1:23 PM, Jim Grosbach wrote: >>> Not really, no. >> >> If you really, really, wanted to do it, you could: >> >> 1) Hack the code generator to not use that register. It might be as simple >> as modifying the TableGen file to not know that the register exists. >> 2) Use inline asm to put the constant into that register and fetch it from >> that register. >> >> The real question is: what larger goal are you trying to accomplish? >> Holding a constant value in a register might not be the best way to do what >> you're doing. >> > I am using LLVM as the code generator for my system emulator. I need > one register holding the address of the CPUState struct. most of the > emulation code is generated by LLVM. a small amount of code is not ( > typically binary patched) . I must make sure that i know in which > register is the CPUState held when i am patching some code.Is there just one CPUState struct for the entire simulator, or are there multiple CPUState structures (e.g., one per simulated CPU) and you want to keep them handy because you use them all the time? If it's the former, why not just use a global variable? If it's the latter, there's probably a few options: 1) Use a thread-local global variable. Each simulated process is a thread. 2) Store the CPUState struct at the bottom or top of the stack. To get a pointer to it, mask some bits off the stack pointer using inline asm code. The Linux kernel uses this hack to find the process structure of the user-space process running on the current CPU. 3) Change the code generator. I don't work with the code generator, so I don't know how involved the change is, but I suspect it's pretty small. -- John T.
On Thu, Jul 19, 2012 at 4:04 PM, John Criswell <criswell at illinois.edu> wrote:> On 7/19/12 2:52 PM, Xin Tong wrote: >> >> On Thu, Jul 19, 2012 at 2:28 PM, John Criswell <criswell at illinois.edu> >> wrote: >>> >>> On 7/19/12 1:23 PM, Jim Grosbach wrote: >>>> >>>> Not really, no. >>> >>> >>> If you really, really, wanted to do it, you could: >>> >>> 1) Hack the code generator to not use that register. It might be as >>> simple >>> as modifying the TableGen file to not know that the register exists. >>> 2) Use inline asm to put the constant into that register and fetch it >>> from >>> that register. >>> >>> The real question is: what larger goal are you trying to accomplish? >>> Holding a constant value in a register might not be the best way to do >>> what >>> you're doing. >>> >> I am using LLVM as the code generator for my system emulator. I need >> one register holding the address of the CPUState struct. most of the >> emulation code is generated by LLVM. a small amount of code is not ( >> typically binary patched) . I must make sure that i know in which >> register is the CPUState held when i am patching some code. > > > Is there just one CPUState struct for the entire simulator, or are there > multiple CPUState structures (e.g., one per simulated CPU) and you want to > keep them handy because you use them all the time? > > If it's the former, why not just use a global variable? > > If it's the latter, there's probably a few options:There are more than one emulated CPUs.> > 1) Use a thread-local global variable. Each simulated process is a thread. > > 2) Store the CPUState struct at the bottom or top of the stack. To get a > pointer to it, mask some bits off the stack pointer using inline asm code. > The Linux kernel uses this hack to find the process structure of the > user-space process running on the current CPU.these 2 are definitely possible ways. but the CPU pointer is used extensively over the JITed emulation code. every use might need a mov to a register on x86.> > 3) Change the code generator. I don't work with the code generator, so I > don't know how involved the change is, but I suspect it's pretty small. >I think i will go this way. i would agree with you that the changes might be small.> -- John T. >
> > 3) Change the code generator. I don't work with the code generator, so I > > don't know how involved the change is, but I suspect it's pretty small. > > > I think i will go this way. i would agree with you that the changes > might be small.You can take X86RegisterInfo::getReservedRegs (lib/Target/X86/X86RegisterInfo.cpp) a look. ;) Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj