> then the note handler does memmove itself modifying XMM0 itself loading > it with something completely different. then note handler finishes > continuing the original programm, then XMM0 would contain the garbage > from the note handler! it would look for the program like if registers > randomly change under it!
True enough. If memmove() were the only problem, solving it would be easy. One option: drop MOVOU altogether; another option: save xmm8 (following from what you said). But it's the whole FP edifice that's relevant in the bigger picture: it may be bad practice, but what if I want to compute the next iteration for pi in a note handler? How is the Go runtime going to stop me, or at least make sure I am aware that I should not be doing it rather than give me an incorrect answer that I then use to fire a ballistic missile at the wrong target? (I concede that I have not thought about this much - feel free to think you have to explain this to an idiot.) ++L
