I know now as how the helper methods called for address translation.
In case of slow path, the address translation is done at the end of
block by method "tcg_out_tb_finalize". Any specific reasons for it ?
Thanks,
Gaurav
On 2/10/14, Gaurav Sharma wrote:
> Sorry if i am a bit slow on this,
> 1. F
Sorry if i am a bit slow on this,
1. For ld/st do we will always have a mapping in the CPUTLBEntry ?
2. I see a lot helper functions in /include/exec/software_template.h ,
from where and how do these come into picture ?
3. When is the TLB populated for addresses within RAM device ?
On 2/10/14, Pet
On 10 February 2014 09:46, Gaurav Sharma wrote:
> I was able to trace the flow to some extent but i still have some queries :
> 1. CPUARCHState is the main structure where we store the register
> info. for e.g. - CPUARMState for ARM. We also main some local
> temporaries cpu_R. So where and how ar
I was able to trace the flow to some extent but i still have some queries :
1. CPUARCHState is the main structure where we store the register
info. for e.g. - CPUARMState for ARM. We also main some local
temporaries cpu_R. So where and how are these temporary values
committed to the main structure
On 02/05/2014 11:22 PM, Gaurav Sharma wrote:
> I need some help regarding the flow of generating a TCG op and then
> subsequent translation of any op into target instrn.
That's most of tcg/tcg.c and tcg/foo/tcg-target.c.
tcg_gen_code is the main entry point for beginning the compilation
of the pr
I am working on something where i need to use the primarily the TCG
part of qemu.
I am aware of the basic code flow for TB generation, execution etc.
What I am really looking is the entry / exit points for TCG and also
how the mapping of registers is done. I see there are many temporaries
created a
