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, <lu...@proxima.alt.za> wrote: > > 1. Addition of TSEMACQUIRE system call. Does it have other applications? > > 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 the > > 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·memmove in > > runtime·sighandler > > The right answer here is to have a plan9·memmove 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 > > > > >
