From mboxrd@z Thu Jan 1 00:00:00 1970 References: From: Kenny Lasse Hoff Levinsen Content-Type: text/plain; charset=us-ascii In-Reply-To: Message-Id: <71A3F6B7-CC61-468D-B8B2-3D46AB92483D@gmail.com> Date: Tue, 23 Feb 2016 11:17:57 +0100 To: 9fans@9fans.net Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Subject: Re: [9fans] Go: FP in note handler Topicbox-Message-UUID: 88af3f7e-ead9-11e9-9d60-3106f5b1d025 Ah, no - it is not a system-wide adjustment, but adjustment of the plan9 spe= cific runtime.sighandler implementation and everything called by it directly= . Notes that don't exit the process are queued and should run outside the ac= tual note handler. I think the "magic" code will be isolated, and might fend off accidental fut= ure additions of floating point registers. The magic-ness also only revolves= around avoiding duffzero and duffcopy in some way. I also think that removi= ng conditionals in the compiler will be a positive thing. I still do not know the feasibility of my plan, whether it is possible to do= cleanly, or possible at all. Maybe someone smarter than me with knowledge o= n the matter could chime in and call me an idiot? Avoiding duffcopy should be easy with a simple memmove implementation. If do= ne right, we can also remove the plan9 specific runtime.memmove and only use= the slow memmove in sighandler (The globlal runtime.memmove is implemented u= sing MOVUPS just like duffcopy. Duffcopy is used for blockcopies by the comp= iler in some cases, although I must admit to not know all the cases yet). Avoiding duffzero without compiler assistance is a bit more tricky - global v= ariables, stack on assembly functions, something like that. Best regards, Kenny Levinsen On 23. feb. 2016, at 10.05, lucio@proxima.alt.za wrote: >> Well, avoiding XMM registers in duffcopy/duffzero is one solution, but >> I was thinking of working around them entirely in code called from the >> note handler, so that duffcopy/duffzero can operate as intended on >> plan9, rather than littering the compiler with OS conditionals. >=20 > Do you think you'll be able to sell that to the Go developers? You > ARE talking about a system-wide adjustment and it seems to me that it > will need constant supervision to be maintained. Again, I may have > misunderstood, but it does seem like a maintenance nightmare to me. >=20 > As for: >=20 >> To fix the duffzero, we'd have to fix runtime.goexitsall's buffer >> usage, but to reenable duffcopy, we'd have to look at the much bigger >> runtime.sighandler. >=20 > That is undeniable, but to avoid a different type of maintenance > nightmare, may be the only option. Although "fixing" duffcopy and > duffzero would seem a better, if less efficient option. >=20 > Still, it's the opinion of a none-too-well-informed spectator, do not > let me spoil it for you. In particular, I'm sure I'm not telling you > anything you have not already considered. >=20 > Lucio. >=20 > PS: I do think that it is our responsibility to track each and every > aspect of Go where Plan 9 demands special treatment. Ideally, this > means build flags or specially named modules and a commitment from a > few of us to keep these in sync. Anything else becomes someone else's > responsibility and that is risky. >=20