> Here are my rules of thumb for generating code where the code > generated might change based on some bit of CPU state: > > When you are generating code, if the code you generate will > change based on the contents of something in the CPUState struct, > then the bit of CPUState you are looking at has to be one of: > (1) encoded in the TB flags (or tb->pc or tb->cs_base) > (and gen_intermediate_code_internal() must read and > use the value in tb->tb_flags, not the one in env)
So if changing a bit of context does not cause TB invalidation then it must be captured in cpu_get_tb_cpu_state and gen_intermediate_code_internal must use that captured value? > (2) always constant for the life of the simulation > (eg env->features if you have some sort of > "target feature support" flags) > (3) specially handled so that when it changes then > all TBs or at least all affected TBs are flushed > (env->breakpoints is in this category), and also > if the change is the result of some instruction then > you must terminate the TB after that instruction. > This is often used for things that rarely change and/or > where you can't fit the whole value into tb_flags. > The reason for this is that the CPUState you're passed in > is not guaranteed to be the state of the CPU at the PC > which you are starting translation from. > > This is the xtensa port at > http://jcmvbkbc.spb.ru/git/?p=dumb/qemu-xtensa.git;a=shortlog;h=refs/heads/xtensa > right? Yes. > It looks like you're breaking these rules with a lot of > the fields in your DisasContext. (Most obviously, you > need to translate code from tb->pc, not env->pc, and > xtensa_get_ring() and xtensa_get_cring() should not read > from env->sregs[PS]. But you should be clear for every > field in DisasContext which category it falls into.) Thank you Peter. Will go rearrange that mess. -- Thanks. -- Max
