Re: [9fans] broken floating point exceptions and fpregs

[lucio@proxima.alt.za]

> On May 26, 2013, at 1:57, lucio@proxima.alt.za wrote:
>
>> It is unreasonable to expect a community to contribute to the
>> development of Plan 9 if the goal posts move with the fashion...
>
> You may agree or not with Erik's position, but this is an
> unreasonable characterization of it.  It actually feels exactly
> backwards to me: he's proposing we *not* move the goalposts (or move
> them much less).  I don't believe he's saying not to support SSE, but
> rather to support it in the more modern kernel.  386 would still be
> around, but putting effort into amd64 is likely the more productive
> use of time.

I guess we're looking at the issue from different philosophical points
of view and we miss the wood for the trees: Erik is in a position to
use the most recent available equipment, my most recent "386"
motherboard is the only one with SATA on board and an Intel 64-bit
CPU.

My criticism lies with a propensity to disregard the impact of
following the fashion has on primitive equipment like mine: if SSE2 is
_enforced_ as the only option (as nearly happened with Go - more about
that in a minute), then, like Alef and IL, we'll lose conventional 387
capabilities and most of my equipment, specially some of my more
expensive stuff like the co-located server in Cape Town, will become
redundant.  This has two drawbacks for me: (a) the comfortable niche
Plan 9 found in my environment will be lost as I will no longer have
the same confidence in Plan 9 I built in the last many years and (b)
I will no longer have the equipment to assist with further development
of Plan 9.

Also, let me make it clear that I meant absolutely no disrespect
towards Erik personally or of his contribution to the Plan 9 project;
on the contrary, I have every reason to be grateful to Erik for the
many ways in which he has assisted the project and, frequently, helped
me personally.

You seem to have misunderstood my position as criticising Erik for
abandoning SSE2 on the 32-bit equipment.  I was trying to suggest that
we should not abandon 387 on the same and, to make things clear, I
have no concern if we discard 387 capabilities in the 64-bit world, as
long as we don't reflect that where 387 is the only option.  I'm not
sure how we got these wires crossed :-)

Going back to the 387/SSE2 issue, in the Go development forum
discussion has stopped without resolving the issue of how to deal with
the need to continue to support the 387 instructions while also
wanting to benefit from the more powerful and, I presume, efficient
SSE2 alternative.  As these are mutually exclusive (go figure!) the
immediate problem is that the Go developers had to choose which option
to release for Go 1.1.  The choice went with SSE2, which means that a
smaller number of users needed to build Go from sources.  It was easy
for me to agree with that decision, I'm prepared to pay a reasonable
price to retain the ability to use Go and, in my case, I build Go from
sources all the time anyway.  I think those who cannot do so can
probably pressure others besides the Go developers to release binary
Go versions for slightly different architectures.

There are two outstanding issues, though.  On the one hand, the
problem the Go developers faced is also a pain for Go users that want
to release software (applications, for example) to the public.  On the
other, there is no clear strategy on how to hold different versions of
the Go toolchain as well as Go applications for the 386 architecture:
discrimination in the file system ends at the architecture and taking
it a level further seems too burdensome for the nett gain.

++L