From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <8286dc5b2020021773af3b8b0a73ee9e@proxima.alt.za> References: <8286dc5b2020021773af3b8b0a73ee9e@proxima.alt.za> Date: Mon, 2 Dec 2013 23:23:38 -0800 Message-ID: From: Skip Tavakkolian To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=089e01538594e234e104ec9c2ca8 Subject: Re: [9fans] Go and 21-bit runes (and a bit of Go status) Topicbox-Message-UUID: 90a73f70-ead8-11e9-9d60-3106f5b1d025 --089e01538594e234e104ec9c2ca8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable BTW, another big item that I forgot to mention, which ironically has been the Subject of this thread, is the support for 21bit runes. On Mon, Dec 2, 2013 at 11:10 PM, wrote: > > 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 > Plan 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=B7memmove in > > runtime=B7sighandler > > The right answer here is to have a plan9=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 > > > > > --089e01538594e234e104ec9c2ca8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
BTW, another big item that I forgot to mention, which iron= ically has been the Subject of this thread, is the support for 21bit runes.=



On Mon, Dec 2, 2013 at 11:10 PM, <lucio@proxima.alt.za> = wrote:
> 1. Addition of TSEMACQUIRE system call. =A0Does it h= ave other applications?

I missed this; is there any documentation that clarifies this issue?<= br> 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 lib= bio on Plan 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.<= br> The macros, on the other hand, are an embarrassment and trigger dozens
of warnings (to the best of my ability to check). =A0There 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 t= he
> test case from Anthony that reproduces it, below). Go team accepted th= e
> patch to get around this, even though it is a bug in Plan 9's 8c.<= br>
The patch was a bit of a scream. =A0I'm the first to admit that 8= c 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. =A0And 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=B7memmove in
> runtime=B7sighandler

The right answer here is to have a plan9=B7memmove until Bell Labs figure a way to classify some opcodes as other than floating point and
allow them where the architecture permits it. =A0It's a big problem, bu= t
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





--089e01538594e234e104ec9c2ca8--