On Wed, Jan 5, 2011 at 05:59, Edgar E. Iglesias wrote:
> On Tue, Jan 04, 2011 at 02:43:11PM -0500, Mike Frysinger wrote:
>> i've been working on a new architecture port, but i cant quite figure
>> out some of the intricacies from reading the code. i have all the
>> simple stuff working for linux-user (register moves, immediate moves,
>> loads, stores, syscall emulation) and want to move on to the next big
>> piece -- code flow changes.
>>
>> i cant quite figure out the difference between DISAS_TB_JUMP and
>> DISAS_JUMP. the exec-all.h header says one is for "only pc was
>> modified dynamically" while the other is "only pc was modified
>> statically". is this referring to conditional vs unconditional jumps
>> ? or is this referring to direct vs indirect jumps ?
>> conditional: if cc jump 1f;
>> unconditional: jump 1f;
>> direct: jump foo;
>> indirect: P0 = [SP++]; jump (P0);
>
> I think it's referering to the latter + some other rules but:
> is_jmp is a port local var and the DISAS_XXX states are used in slightly
> different ways by different ports depending on the needs. Some ports only
> use some of the states. When branching, what really matters is how and when
> you end the TB. You need to bring the runtime state up-to-date and end the
> TB by potentially jumping to another one (tcg_gen_goto_tb) and by
> exiting (tcg_gen_exit_tb).
>
> To be able to jump directly between TB's you need to follow some rules:
> Not jump across pages. Not jump from a TB that has modified it's TB
> dependant CPU state in a dynamic way. Also the destination address must be
> derived from data available at translation time, e.g not an indirect
> register branch/jump. + I probably forgot something :). These rules
> are related to the DISAS_XXX comments you were wondering about.
>
> For some arch's branching is a fairly easy matter, for others it can be
> quite complicated. Delayslots, MMU aborts, variable length ISA encoding
> and other details can all come together to make things hairy. It's not
> all 100% clear to me either so I hope I'm not missleading you here. If
> so, someone will probably correct me.
thanks for the info ... my arch doesnt have to deal with crazy stuff
like that. it has fixed insn length (2 or 4 bytes) and no delayed
branching. so it should be somewhat like arm/i386 i think.
could you elaborate on the tcg_gen_goto_tb and tcg_gen_exit_tb stuff ?
i think i have all the other pieces squared away in my head now
(labels/branches/conditions). but i cant quite grasp the meaning of
the arguments to the tb goto/exit points.
this x86_64 asm has direct correlations to my own ISA:
.global _start
_start:
mov $60, %rax
mov $6, %rcx
mov $0, %rbx
1: add $1, %rbx
cmp %rcx, %rbx
jl 1b
int $0x80;
basically i set the syscall number to __NR_exit, set the first
argument to 0, and then increment it until the argument is 6. then
the program exits with status of 6.
the tcg ops that the branch generates are:
movi_i32 cc_op,$0x11
add_i64 tmp8,cc_dst,cc_src
brcond_i64 tmp8,cc_src,lt,$0x0
goto_tb $0x0
movi_i64 tmp4,$0x4000ce
st_i64 tmp4,env,$0x80
exit_tb $0x7fd7a475f088
set_label $0x0
goto_tb $0x1
movi_i64 tmp4,$0x4000c5
st_i64 tmp4,env,$0x80
exit_tb $0x7fd7a475f089
what meaning do the goto_tb arguments (0 and 1) have ? the exit_tb
args appear to be the actual tb pointers, but for some reason the
second one is set to the pointer+1. i guess this is significant ?
when i attempt to generate the same thing, qemu hits a loop on me. i
guess i'll have to throw both into gdb and find out where it is going
wrong.
-mike
