Re: [Qemu-devel] [PATCH 0/4] new Blackfin QEMU port

[Mike Frysinger]

On Tue, Feb 1, 2011 at 13:45, Peter Maydell wrote:
> On 1 February 2011 18:16, Mike Frysinger wrote:
>> On Tue, Feb 1, 2011 at 12:30, Peter Maydell wrote:
>>> That's OK too, that would fall into my category (3).
>>
>> so the TB invalidation checking can be taken care of implicitly if i
>> handled things in cpu_get_tb_cpu_state() ?  that would be nice.
>
> It doesn't invalidate the TB, it just means that qemu can have
> two different TBs for the same address and distinguish between
> them. So in cpu_get_tb_cpu_state() you encode the relevant bits
> of env into the flags, and then in translate.c, instead of looking
> at env members, you unpack tb->flags (usually into a disas context
> struct) and look at the results of your unpacking.

right.  same thing for me.

>> but i guess i'm not seeing how i would handle this scenario ... i want
>> to attach to each TB the state of the two 32bit lbregs when that TB
>> was created.  then in this state func, make sure the current lbregs
>> have the same values.  but if i need to encode this information into
>> "flags", i dont think i have enough space.
>
> That's right -- you only have a total of 64 bits (you can use flags
> and also cs_base since you're not a PC with a weird addressing
> setup), so you have to be stingy about what you put in there.
> Also if you're likely to repeatedly execute the same bit of code
> with different values of lbregs you probably don't want to put them
> in tb_flags anyway, because you'd end up repeatedly translating
> the code and holding lots of nearly-identical TBs for it.

lbregs are not likely to be changed to weird values, or dynamically.
the vast majority of the time, their values are encoded at link time
to fixed offsets, and any time the code is executed the lbregs will
remain the same.  so in practice, this wont come up -- all compiler
generated code and every handwritten assembly code ive seen works this
way.  i set up the framework the way i did so that it would
(hopefully) work correctly in pathological cases of lbregs being
changed in weird/dumb ways.

while it would be nice to use this function, it seems like i'll have
to stick with my current method of managing things by hand.  i can
think of at least one flag that could be used here (ASTAT's RND_MOD),
so i'll need the flags for actual flags.
-mike