Please don't ban assembly in user packages. If people are using assembly
it's because they have no better option, it's really the last option in a
long list of distasteful options for improving the speed of the code.
I suspect nobody uses lightly, I only use it when I have exhausted all
other options and it's still too slow. Often this is because the compiled
Go code cannot compete with cases where there is a processor instruction
that does the same (e.g. bsr or bswap).
Because most of the benefit in such cases is lost to the function call (no
inlinable asm functions yet) I manually inline the asm by compiling,
disassembling the caller, copying it into a .s file and then manually
inlining the asm function. I think most cases I have to do this manual
inlining because if the asm function were sufficiently bulky that the call
overhead didn't matter, then I would have just written it in C and used cgo
(again using assembly is the very last resort.)
I really like that Go empowers me by at least allowing assembler if I find
myself in the unhappy situation of having exhausted all other available
options. I don't care that it's not documented and that it may break with
future releases, I just care that it is possible rather than impossible.
On Wednesday, September 24, 2014 3:56:49 PM UTC-5, Dmitry Vyukov wrote:
We've banned C in user packages. But assembly is not less dangerous to
use with respect to stack pointers information. Do we want to say
something about assembly in docs or in release notes?
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to email@example.com.
For more options, visit https://groups.google.com/d/optout.