Re: [Qemu-devel] [PATCH 16/17] s390x: translate engine for s390x CPU

[Alexander Graf]

On 29.03.2011, at 11:56, Peter Maydell wrote:

> On 29 March 2011 10:25, Alexander Graf <address@hidden> wrote:
>> On 29.03.2011, at 11:17, Peter Maydell wrote:
>>> On 29 March 2011 09:55, Alexander Graf <address@hidden> wrote:
>>>> On 28.03.2011, at 17:40, Peter Maydell wrote:
>>>>> Doesn't this take you over MAX_OP_PER_INSTR for some cases?
>>>> 
>>>> I haven't encountered any case where it does.
>>> 
>>> Really? MAX_OP_PER_INSTR's only 96, so if you have 16 registers
>>> in your loop then it only needs 6 ops per register to hit that,
>>> and the op 0x96 case looks like it must generate more than that.
>>> 
>>> I have an item on my todo list to see if I can add an assert()
>>> check for this limit, because there are cases for Neon load/stores
>>> that apparently hit it.
>> 
>> Hrm - might be useful to increase MAX_OP_PER_INSTR then, no?
> 
> The TCG README suggests that 20 ops is the point at which it's
> better to use a helper function. I don't know if that advice
> still holds true or not.

Well, the amount of stores / loads stays the same throughout a helper or not. 
The main reason to not use a "heavy" helper is that all the register values 
need to be flushed out, adding quite substantial overhead for the stores/loads 
on those. When flushing them, tcg also loses its ability to predict which 
values are used, so dead code elimination is moot.

So yes, complex operations that could be optimized by a C compiler should go 
into helpers - preferably if they only use input and output values that get 
passed as registers. As soon as they touch memory or env though, the world 
isn't as great anymore :(.

> 
>>>> The user code needs to know where it jumps back to, while the
>>>> exception generation code needs to get the exact position it was
>>>> in to generate some more metadata.
>>> 
>>> Ah. For ARM we do this by advancing env->regs[15] in linux-user/main.c
>>> cpu_loop() when we get an EXCP_SWI. It looks like we do it that way
>>> for MIPS and SPARC at least too, so I guess it would be better for
>>> s390 to follow that pattern.
>> 
>> Unfortunately, it's not that easy as there are 2 different ways of
>> issuing an SVC (actual SVC and EXECUTE instruction), both of which
>> having different instruction lengths. So we really need to keep the
>> information in the instruction decoder :(
> 
> Does a Linux kernel running on a real s/390 system have to deal with
> the distinction in its SVC entrypoint?

An s390 kernel gets the size information as interrupt parameter, so it can 
simply calculate the NIP from that.


Alex