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, <lucio@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
>
>
>
>
>