From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <79f3a84204e48d8db164a97795bddda1@proxima.alt.za> To: 9fans@9fans.net Date: Sun, 2 Jun 2013 17:54:14 +0200 From: lucio@proxima.alt.za In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Go and 21-bit runes (and a bit of Go status) Topicbox-Message-UUID: 5fc1940a-ead8-11e9-9d60-3106f5b1d025 > 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