> On May 26, 2013, at 1:57, lu...@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 a
On May 26, 2013, at 1:57, lu...@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 feel
my terminal runs a plan 9 also with
those bits. dont worry.
On May 26, 2013, at 8:00 AM, lu...@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?
>
>
> ++L
>
> 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?
++L
> 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 un
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
On Sat May 25 11:41:44 EDT 2013, kh...@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 se
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?
On Sat May 25 09:59:39 EDT 2013, kh...@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 ar
On Sat May 25 10:56:31 EDT 2013, cinap_len...@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 i
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
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?
On Fri May 24 17:30:59 EDT 2013, cinap_len...@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
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.
--
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, bu
15 matches
Mail list logo
