Re: [9fans] Go: FP in note handler

[Kenny Lasse Hoff Levinsen <kennylevinsen@gmail.com>]

Ah, no - it is not a system-wide adjustment, but adjustment of the plan9 specific runtime.sighandler implementation and everything called by it directly. Notes that don't exit the process are queued and should run outside the actual note handler.

I think the "magic" code will be isolated, and might fend off accidental future additions of floating point registers. The magic-ness also only revolves around avoiding duffzero and duffcopy in some way. I also think that removing 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 on the matter could chime in and call me an idiot?

Avoiding duffcopy should be easy with a simple memmove implementation. If done right, we can also remove the plan9 specific runtime.memmove and only use the slow memmove in sighandler (The globlal runtime.memmove is implemented using MOVUPS just like duffcopy. Duffcopy is used for blockcopies by the compiler 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 variables, 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.
> 
> 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.
> 
> As for:
> 
>> 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.
> 
> 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.
> 
> 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.
> 
> Lucio.
> 
> 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.
>