|
From: Tom H. <to...@co...> - 2012-09-24 17:40:53
|
On 24/09/12 18:37, Petar Jovanovic wrote: > @Julian,Tom > So, for the si_code, the answer is 'no', the value was not correct. The issue is > that the si_code variable can have two values (see the part of the original code > that we are deleting with this patch). The value in si_code depends on the > 'code' field in the TEQ instruction. So, with a single synth_sigfpe we can only > cover one case, and ignore the second case (or maybe even assert for this case > in priv/guest_mips_toIR.c, which we should avoid, if possible - see the change > in the attached patch - I would like to remove that but I am leaving it for the > sake of conversation). Should we have two Ijk_SigFPEs, like Ijk_SigFPE1 and > Ijk_SigFPE2, and multiply the rest of the code needed for this? Or something > else? Yes, generating the right code is a sticky issue. I'm pretty sure some of the existing synthesised signals get it wrong because of this lack of information. What we've generally done I think is punted and just generated one of the codes, or maybe zero and hoped nothing minds too much about the details being exactly right. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |