[9fans] broken floating point exceptions and fpregs

[9fans] broken floating point exceptions and fpregs

[cinap_lenrek]

the sse change broke floating point exception handling.

from /sys/src/9/pc/main.c:^matherror()
	/*
	 *  save floating point state to check out error
	 */
	fpenv(&up->fpsave);
	mathnote();

this is wrong, because fpenv() will store the enviroment
in x87 format, but mathnote() uses mathstate() which intreprets
the FPsave structure depending on if sse was enabled or not.

a fix for this was just commited in 9front which passes the
status word and fppc explicitely to mathnode() and uses
mathnote(up->fpsave.status, up->fpsave.pc); in matherror()
and the values extracted by mathstate() in mathemu().

the 2nd problem is how we'r going to handle the fpregs file
in devproc. as this change changes the format. fpr() in acid
returns garbage right now. any thoughts on it how to move
forward on this?

--
cinap

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

[cinap_lenrek]

following up on the fpregs... it is possible to have a little
acid library like /sys/lib/acid/sse that just remaps the fpregs
mapping and redefines the E0-7 and F0-7 symbols fpr() functions.

so when debugging fp on a new kernel, one could just attach with
acid -lsse and everything would work.

--
cinap

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

[erik quanstrom]

On Fri May 24 17:30:59 EDT 2013, cinap_lenrek@gmx.de wrote:
> the sse change broke floating point exception handling.
>
> from /sys/src/9/pc/main.c:^matherror()
> 	/*
> 	 *  save floating point state to check out error
> 	 */
> 	fpenv(&up->fpsave);
> 	mathnote();
>
> this is wrong, because fpenv() will store the enviroment
> in x87 format, but mathnote() uses mathstate() which intreprets
> the FPsave structure depending on if sse was enabled or not.
>
> a fix for this was just commited in 9front which passes the
> status word and fppc explicitely to mathnode() and uses
> mathnote(up->fpsave.status, up->fpsave.pc); in matherror()
> and the values extracted by mathstate() in mathemu().

http://ftp.9atom.org/9pccpuf-sse

this is a different implementation that steve simon used to
run linuxemu.

> the 2nd problem is how we'r going to handle the fpregs file
> in devproc. as this change changes the format. fpr() in acid
> returns garbage right now. any thoughts on it how to move
> forward on this?

why don't we just let the 386 kernel rest in peace and use
64-bit for sse?

- erik

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

[Kurt H Maier]

On Sat, May 25, 2013 at 09:47:05AM -0400, erik quanstrom wrote:
>
> why don't we just let the 386 kernel rest in peace and use
> 64-bit for sse?
>

Let's all go buy new computers instead of using the ones we have?

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

[cinap_lenrek]

the url http://ftp.9atom.org/9pccpuf-sse points to a binary file...

wheres the source? how does this implementation differ from the
sources one?

--
cinap

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

[erik quanstrom]

On Sat May 25 10:56:31 EDT 2013, cinap_lenrek@gmx.de wrote:
> the url http://ftp.9atom.org/9pccpuf-sse points to a binary file...
>
> wheres the source? how does this implementation differ from the
> sources one?

that's just a fossil-supporting kernel.  you can also boot from a
file server over il or tcp.

i don't have source i can distribute yet.  there was also a choice
made in using the FPARCH from nix that spills over into the
other arches.  it was proablly a bad idea.  i'll try to pull something
together this afternoon.

- erik

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

[erik quanstrom]

On Sat May 25 09:59:39 EDT 2013, khm-9@intma.in wrote:
> On Sat, May 25, 2013 at 09:47:05AM -0400, erik quanstrom wrote:
> > 
> > why don't we just let the 386 kernel rest in peace and use
> > 64-bit for sse?
> 
> Let's all go buy new computers instead of using the ones we have?

x86_64 has been around since 2003, and on nearly every x86 machine for
the last 8 years.  sse2 has been around since 2001.  there is not a large
percentage of currently-running x86 machines that have sse2 but do not have
x64-bit extensions, and this percentage is generally decreasing.

i put sse2 in the 386 kernel a few years ago, before the compilers supported
it.  this was to support a linuxemu project.  the linux tools needed sse.

however, when it came to putting sse2 into a general kernel—and that
includes answering questions cinap is posing, like how do we deal with
different abis in the debugger, etc.—it seemed more disruption than it
was worth.  now that the 64-bit kernel is real, and supports even low-end
hardware like atom, i would rather concentrate on making
the 64-bit kernel better.

- erik

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

[Kurt H Maier]

On Sat, May 25, 2013 at 11:02:16AM -0400, erik quanstrom wrote:
> now that the 64-bit kernel is real,

Where can I find it?

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

[erik quanstrom]

On Sat May 25 11:41:44 EDT 2013, khm-9@intma.in wrote:
> On Sat, May 25, 2013 at 11:02:16AM -0400, erik quanstrom wrote:
> > now that the 64-bit kernel is real,
>
> Where can I find it?

9fs atom; cd /n/atom/sys/src/nix

i am not running any 386 machine any longer.  just arm and amd64.
the file server uses usb for 9fat:, but doesn't have an independent file
system.

a few notes on dependencies:

- it does depend on *e820 (note: this is not the old e820 format) being
set by the boot loader.  i think the 9front boot loader is compatable,
as 9atom's default boot loader is derived from cinap's good work.

- it may depend on getbe(2) (http://www.9atom.org/magic/man2html/2/getbe),
depending on the devices you compile in.

- erik

---
; sed -n '/case atom/,/case/p' < /bin/9fs
case atom
	# import -E ssl atom.9atom.org /n/atom /n/atom
	srv $nflag -q tcp!atom.9atom.org atom &&
		mount $nflag /srv/atom /n/atom atom
case atomdump

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

[Francisco J Ballesteros]

did not publish it yet, but we have what 
could be called a nix mark II, comes
with a new mount table and a fossil
speaking 9pix, plus a new scheduler. 

It does not have al the stuff like graphics in the modified mark I nix 
you have, but, the new stuff should be
easy to use on it. 

give us a bit more time and we will put 
the new bits somewhere. 

hth

On May 25, 2013, at 5:02 PM, erik quanstrom <quanstro@quanstro.net> wrote:

> On Sat May 25 09:59:39 EDT 2013, khm-9@intma.in wrote:
>> On Sat, May 25, 2013 at 09:47:05AM -0400, erik quanstrom wrote:
>>> 
>>> why don't we just let the 386 kernel rest in peace and use
>>> 64-bit for sse?
>> 
>> Let's all go buy new computers instead of using the ones we have?
> 
> x86_64 has been around since 2003, and on nearly every x86 machine for
> the last 8 years.  sse2 has been around since 2001.  there is not a large
> percentage of currently-running x86 machines that have sse2 but do not have
> x64-bit extensions, and this percentage is generally decreasing.
> 
> i put sse2 in the 386 kernel a few years ago, before the compilers supported
> it.  this was to support a linuxemu project.  the linux tools needed sse.
> 
> however, when it came to putting sse2 into a general kernel—and that
> includes answering questions cinap is posing, like how do we deal with
> different abis in the debugger, etc.—it seemed more disruption than it
> was worth.  now that the 64-bit kernel is real, and supports even low-end
> hardware like atom, i would rather concentrate on making
> the 64-bit kernel better.
> 
> - erik

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

[lucio]

> x86_64 has been around since 2003, and on nearly every x86 machine for
> the last 8 years.  sse2 has been around since 2001.

Percentages don't cut it for me.  I have one x64 workstation, the rest
of my network is 32-bits.  Including my Internet-facing server running
on VMware ESXi 3.5.

It is unreasonable to expect a community to contribute to the
development of Plan 9 if the goal posts move with the fashions, only
wealthy and/or fickle developers would be allowed to participate.

I am with Kurt (and the NetBSD developers) on this one: history is
precious and painfully acquired skills cannot be thrown away at the
whim of the fashionistas.

++L

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

[lucio]

> give us a bit more time and we will put
> the new bits somewhere.

You are back-porting this to the Bell Labs distribution, I hope?
<grin>

++L

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

[Francisco J Ballesteros]

my terminal runs a plan 9 also with
those bits. dont worry.

On May 26, 2013, at 8:00 AM, lucio@proxima.alt.za wrote:

>> give us a bit more time and we will put
>> the new bits somewhere.
>
> You are back-porting this to the Bell Labs distribution, I hope?
> <grin>
>
> ++L
>

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

[Anthony Sorace]

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.

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

[lucio]

> 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