On 29 March 2011 10:25, Alexander Graf <ag...@suse.de> wrote: > On 29.03.2011, at 11:17, Peter Maydell wrote: >> On 29 March 2011 09:55, Alexander Graf <ag...@suse.de> 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. >>> 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? -- PMM