On Sat, Apr 2, 2011 at 1:33 AM, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 1 April 2011 19:29, Blue Swirl <blauwir...@gmail.com> wrote: >> On Fri, Apr 1, 2011 at 5:30 PM, Peter Maydell <peter.mayd...@linaro.org> >> 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. > >> I didn't check, but if neon_helper.c is compiled like op_helper.c, >> passing env should not be needed. > > It isn't; see the comments when this patch was first posted. > >> If that is not the case, the >> functions could be moved to op_helper.c. > > Nobody seemed to have a coherent rule about when functions > should be in op_helper.c and use the global 'env' variable > and when they should be in some other file and have 'env' > passed as a parameter (or indeed why only op_helper.c > should be special in this way). Currently the ARM target has > both kinds of helper function. So I took the straightforward > approach of not moving code around wholesale, and just > passed in the env pointer, consistent with the way we already > handle most functions that talk to softfloat.
In general, helpers for the translated code belong to op_helper.c. They can and should access global env directly for speed. If a helper is used for both translated code and outside of it, a wrapper should be added to do global env shuffling (or for example a copy without shuffling added).
