On 20 July 2017 at 16:04, Alex Bennée <alex.ben...@linaro.org> wrote: > So while any review is gratefully accepted my main interest is if this > sort of duel approach is worth it? > > I think the long term aim would be to move fully over to the newer > library if we can but I appreciate a not inconsiderable amount of work > has gone into the existing 2a code. Having said that as long as the > testing is good we are likely to pick up bugs in both implementations. > While its nice to have a more modern SoftFloat library it still lags > somewhat on QEMUs general requirements claiming only direct support > for IEEE754 1985 whereas most modern CPUs are closer to the 2008 > revision of the specification.
I'm definitely not a fan of having two different implementations of softfloat in the codebase, except perhaps for some well defined *short* transition period. Otherwise we'll end up carrying both of them around forever, given our past history at success in transitioning things to new APIs. I don't have a strong view about whether we're better off moving to softfloat3c and forward porting any bugfixes and improvements, or backporting 16-bit fp code from 3c to our current codebase. thanks -- PMM
