Re: [Qemu-devel] [PATCH 1/7] target-arm: Make Neon helper routines use correct FP status
On Mon, Mar 28, 2011 at 03:15:08PM +0100, Peter Maydell wrote: On 14 March 2011 05:35, Nathan Froyd froy...@codesourcery.com wrote: Oh, right. I am ambivalent as to whether passing env to such functions is the right thing to do or not. So did this amount to a request for a change to this patchset, or are you happy to let it pass? I am happy to let it pass. -Nathan
Re: [Qemu-devel] [PATCH 1/7] target-arm: Make Neon helper routines use correct FP status
On 14 March 2011 05:35, Nathan Froyd froy...@codesourcery.com wrote: On Fri, Mar 11, 2011 at 10:31:31PM +, Peter Maydell wrote: On 11 March 2011 18:30, Nathan Froyd froy...@codesourcery.com wrote: Is there a reason that you don't simply use the global env rather than passing in an extra parameter everywhere? Just following the pattern that generally seems to be used by most helper functions, ie if you want the CPU env pass it in as a parameter. As far as I know, you can't use the global env unless you're in op_helper.c because that's the only source file compiled with the right flags. Oh, right. I am ambivalent as to whether passing env to such functions is the right thing to do or not. So did this amount to a request for a change to this patchset, or are you happy to let it pass? (I'm planning to stick this patchset into a pull-request with some of the other ARM patches that have had a few weeks for review comment later this week, so if you'd like a change now would be a good time to say so...) thanks -- PMM
Re: [Qemu-devel] [PATCH 1/7] target-arm: Make Neon helper routines use correct FP status
On Fri, Mar 11, 2011 at 10:31:31PM +, Peter Maydell wrote: On 11 March 2011 18:30, Nathan Froyd froy...@codesourcery.com wrote: Is there a reason that you don't simply use the global env rather than passing in an extra parameter everywhere? Just following the pattern that generally seems to be used by most helper functions, ie if you want the CPU env pass it in as a parameter. As far as I know, you can't use the global env unless you're in op_helper.c because that's the only source file compiled with the right flags. Oh, right. I am ambivalent as to whether passing env to such functions is the right thing to do or not. I wonder if it'd be worthwhile just to merge these functions into op_helper.c, since we have a proper FP status for NEON bits now. Why move these and not (for instance) the VFP helpers in helper.c which use the CPU env for more or less the same reasons? No reason, other than that I wasn't thinking about the VFP helpers. :) -Nathan
Re: [Qemu-devel] [PATCH 1/7] target-arm: Make Neon helper routines use correct FP status
On Fri, Mar 11, 2011 at 06:12:20PM +, Peter Maydell wrote: Make the Neon helper routines use the correct FP status from the CPUEnv rather than using a dummy static one. This means they will correctly handle denormals and NaNs and will set FPSCR exception bits properly. Is there a reason that you don't simply use the global env rather than passing in an extra parameter everywhere? I wonder if it'd be worthwhile just to merge these functions into op_helper.c, since we have a proper FP status for NEON bits now. -Nathan
Re: [Qemu-devel] [PATCH 1/7] target-arm: Make Neon helper routines use correct FP status
On 11 March 2011 18:30, Nathan Froyd froy...@codesourcery.com wrote: On Fri, Mar 11, 2011 at 06:12:20PM +, Peter Maydell wrote: Make the Neon helper routines use the correct FP status from the CPUEnv rather than using a dummy static one. This means they will correctly handle denormals and NaNs and will set FPSCR exception bits properly. Is there a reason that you don't simply use the global env rather than passing in an extra parameter everywhere? Just following the pattern that generally seems to be used by most helper functions, ie if you want the CPU env pass it in as a parameter. As far as I know, you can't use the global env unless you're in op_helper.c because that's the only source file compiled with the right flags. I wonder if it'd be worthwhile just to merge these functions into op_helper.c, since we have a proper FP status for NEON bits now. Why move these and not (for instance) the VFP helpers in helper.c which use the CPU env for more or less the same reasons? -- PMM