From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <8286dc5b2020021773af3b8b0a73ee9e@proxima.alt.za> To: 9fans@9fans.net Date: Tue, 3 Dec 2013 09:10:31 +0200 From: lucio@proxima.alt.za In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Go and 21-bit runes (and a bit of Go status) Topicbox-Message-UUID: 909b2690-ead8-11e9-9d60-3106f5b1d025 > 1. Addition of TSEMACQUIRE system call. Does it have other application= s? I missed this; is there any documentation that clarifies this issue? I think it's important to provide a rationale for structural changes and Bell Labs are a little too glib with their patch releases, in my opinion. > 2. Use of Go's libbio, rather than Plan 9's. Alternatively libbio on Pl= an 9 > can be changed. It's not clear to me why this would be a bad thing. The functions are very readily added to libbio without side effects. The macros, on the other hand, are an embarrassment and trigger dozens of warnings (to the best of my ability to check). There really ought to be no warnings in compiling the Go tool chain for Plan 9; the bison-related stuff deserves some attention, too. > 3. Modifications to 8g to get around an 8c bug (for the curious, see th= e > test case from Anthony that reproduces it, below). Go team accepted the > patch to get around this, even though it is a bug in Plan 9's 8c. The patch was a bit of a scream. I'm the first to admit that 8c needs a touch of TLC and that an abort() in the middle of a compiler, without the slightest attempt to deal with the problem is at least as embarrassing as the expansion of BGETLE, but the original code that tripped the compiler was also extremely shoddy. And the Go developers' resistance to rewrite a few badly thought out lines of code did come back to bite them in the ass. > 4. modification to get around having to use runtime=C2=B7memmove in > runtime=C2=B7sighandler The right answer here is to have a plan9=C2=B7memmove until Bell Labs figure a way to classify some opcodes as other than floating point and allow them where the architecture permits it. It's a big problem, but it needs to be addressed, the world of CPU extensions is still young and, sadly, not still-born. The Go developers will eventually need to adjust to this reality too. Arm64 is a hint of things to come. ++L