From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <35c5de340bd7283e907593e1ba64569f@gmx.de>
Date: Sun,  2 Jun 2013 17:01:15 +0200
From: cinap_lenrek@gmx.de
To: 9fans@9fans.net
In-Reply-To: <f1f540c3c271b35b940f50607d11a615@proxima.alt.za>
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: 5f89c958-ead8-11e9-9d60-3106f5b1d025

> Regarding the latter, Plan 9 does not allow floating point
> instructions to be executed within note handling, but erring on the
> side of caution also forbids instructions such as MOVOU (don't ask me)
> which is part of the SSE(2?) extension, but hardly qualifies as a
> floating point instruction.

The reason for FP being forbidden in note handler is that the kernel only saves
the general purpose (Ureg) registers of the interrupted/notified process
context. The fp or xmm registers are *not* saved and a note handler modifying
those (thru fp instructions or sse instructions) would trash these registers
for the program interrupted by the note.

you could save the ureg, and jump out of the note handler with notejmp(),
save the fp/sse registers yourself and then do the handling of the note
outside of the note context. (this is how signals are implemented in ape).

or we change the kernel to save the fp registers in notify() as well,
pushing them on the user stack and restoring them on noted() just like
the Ureg.

or GO could just stop using *OMG-OPTIMIZED* SSE memmove() in the note
handler.

--
cinap