You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I propose to make the compiler translate various VFP instructions into
direct call to software floating point functions.
There might be even more optimizations available, because the compiler
knows GOARM now, so we can completely change the way GOARM=5
works.
Once we have another architecture (mips) that also needs software
floating point, then this approach makes even more sense as we don't
need to write anther FP instruction decoder in runtime.
The text was updated successfully, but these errors were encountered:
Then use hardware. Seriously. Software floating point is slow. That's the way it is. Not worth spending time on. People who want fast floating point use hardware.
Also, I actually quite like the current approach because it has just one encoding instead of two when looking at the binaries. And in theory you could NOP out the calls to sfloat to turn a software float binary into a hardware float binary.
A MIPS FP instruction decoder does not sound like a lot of code. Maybe 100 lines?
See #10749.
I propose to make the compiler translate various VFP instructions into
direct call to software floating point functions.
There might be even more optimizations available, because the compiler
knows GOARM now, so we can completely change the way GOARM=5
works.
Once we have another architecture (mips) that also needs software
floating point, then this approach makes even more sense as we don't
need to write anther FP instruction decoder in runtime.
The text was updated successfully, but these errors were encountered: