Re: [9fans] extern register

[erik quanstrom]

On Fri Jul 18 22:28:12 EDT 2014, cinap_len...@felloff.net wrote:
> so, we say r14 and r15 arent really special for user programs. and its
> just a c compiler implementation detail that it doesnt allocate these
> registers, but assembly code can freely use them for scratch space
> or whatever. extern register will not work in userspace c programs
> because syscalls will trash these registers.
> 
> makes any sense?

certainly.

speaking for myself, the model that r14 and r15 are off limits for
esoteric reasons is preferrable, given the quite limited maximum
benefit, to the complications of sneaking by the limitation.

obviously, the mips port avoided this by never needing >28 live
registers at once.

- erik

Re: [9fans] extern register

[erik quanstrom]

On Fri Jul 18 22:34:43 EDT 2014, cinap_len...@felloff.net wrote:
> isnt that contradicting what you just said?

i didn't think so.  restated: you could restore the registers, and that
would be right proper, but it wouldn't make a difference unless you're
using some fancy assembly, or a different compiler; it doesn't give the
compiler more freedom.

- erik

Re: [9fans] extern register

[cinap_lenrek]

isnt that contradicting what you just said?

--
cinap

Re: [9fans] extern register

[cinap_lenrek]

so, we say r14 and r15 arent really special for user programs. and its
just a c compiler implementation detail that it doesnt allocate these
registers, but assembly code can freely use them for scratch space
or whatever. extern register will not work in userspace c programs
because syscalls will trash these registers.

makes any sense?

--
cinap

Re: [9fans] extern register

[erik quanstrom]

On Fri Jul 18 22:05:32 EDT 2014, quans...@quanstro.net wrote:
> On Fri Jul 18 21:58:37 EDT 2014, cinap_len...@felloff.net wrote:
> > the amd64 compiler reserves R14 and R15 for extern register
> > declarations. these are used by the kernel for the mach
> > and up pointers, but currently are not preserved during
> > system calls.
> > 
> > would it make sense to save and restore the two registers
> > on syscall entry/exit, so userspace programs could make use
> > of them for per process data?
> 
> i think after some experience (i.e. mistakes) the answer is probablly, no.
> 
> the compiler needs to know for the kernel that r14 and r15 are special and
> not allocate them for the kernel, but what about userland?  what about 
> libraries
> that are shared between them? 
> 
> one can work around these problems by compiling all libraries twice, etc.
> but these are painful compromises.
> 
> in reality, there is only one place in the code that i know of that chews
> through 15 or more registers, and that's the alpha drawing code in
> libmemdraw.  so the solution of just limiting the compiler to r0-r13
> seems to be pretty effective for what we're doing.

i realize i didn't quite answer the question as asked.  restoring
the registers is independent of the compiler.  so yes, you're right!  the 
registers
should be restored.  but at least you know why it's not a disaster that
they are not.

- erik

Re: [9fans] extern register

[erik quanstrom]

On Fri Jul 18 21:58:37 EDT 2014, cinap_len...@felloff.net wrote:
> the amd64 compiler reserves R14 and R15 for extern register
> declarations. these are used by the kernel for the mach
> and up pointers, but currently are not preserved during
> system calls.
> 
> would it make sense to save and restore the two registers
> on syscall entry/exit, so userspace programs could make use
> of them for per process data?

i think after some experience (i.e. mistakes) the answer is probablly, no.

the compiler needs to know for the kernel that r14 and r15 are special and
not allocate them for the kernel, but what about userland?  what about libraries
that are shared between them? 

one can work around these problems by compiling all libraries twice, etc.
but these are painful compromises.

in reality, there is only one place in the code that i know of that chews
through 15 or more registers, and that's the alpha drawing code in
libmemdraw.  so the solution of just limiting the compiler to r0-r13
seems to be pretty effective for what we're doing.

- erik

[9fans] extern register

[cinap_lenrek]

the amd64 compiler reserves R14 and R15 for extern register
declarations. these are used by the kernel for the mach
and up pointers, but currently are not preserved during
system calls.

would it make sense to save and restore the two registers
on syscall entry/exit, so userspace programs could make use
of them for per process data?

--
cinap

Re: [9fans] sam for Windows?

[6o205zd02]

On 7/10/2014 9:43 AM, Russ Cox rsc-at-swtch.com |9fans| wrote:
On Thu, Jul 3, 2014 at 1:39 AM, <6o205z...@sneakemail.com 
> wrote:


On 6/27/2014 4:38 PM, Russ Cox rsc-at-swtch.com
 |9fans| wrote:

However, Steve Simon buried the lede in his reply:
https://bitbucket.org/knieriem/pf9/downloads has a working
sam, acme, plumber, etc in binary form. I just tested that sam
and acme from there both work on my fussy 64-bit Windows
machine. And they're in color!

Thanks Russ, This sounds great (given that haven't been able to
completely eliminate Windows from my life).  Unfortunately, I
can't seem to figure out quite what I need to do to install and/or
build it so that acme works.  The documentation at
https://bitbucket.org/knieriem/pf9 confuses me, since it talks
about running mk, but I can't find an mk executable in any of the
downloads.

Can you describe the steps you took to install/run it?


i just ran the binaries in the downloads. i haven't tried to build 
anything.


There are 5 downloads at https://bitbucket.org/knieriem/pf9/downloads.  
Which one(s) did you use?


thanks,
Peter Canning

Re: [9fans] file server speed

[Bakul Shah]

On Fri, 18 Jul 2014 15:36:09 EDT erik quanstrom  wrote:
> On Fri Jul 18 12:51:49 EDT 2014, 23h...@gmail.com wrote:
> > > perhaps high-efficiency wall warts could make up much of the difference.
> > > picked at random (first link) ...
> > >
> > > http://www.amazon.com/Nokia-AC-10U-Micro-USB-Efficiency-Charger/dp/B00DP0
> TQLG
> > >
> > 
> > Given that the rpi has some weird power issues and without
> > specification of the amperage of the charger this might be bad advice.
> 
> good point.  thanks for pointing that out.

The new B+ has a switching regulator. It uses less power and
it is more tolerant of voltage changes -- below 5V USB will
stop working but there are reports of booting Linux to login
screen on as low as 2.6V. So power issues should be resolved.

Re: [9fans] file server speed

[erik quanstrom]

On Fri Jul 18 12:51:49 EDT 2014, 23h...@gmail.com wrote:
> > perhaps high-efficiency wall warts could make up much of the difference.
> > picked at random (first link) ...
> >
> > http://www.amazon.com/Nokia-AC-10U-Micro-USB-Efficiency-Charger/dp/B00DP0TQLG
> >
> 
> Given that the rpi has some weird power issues and without
> specification of the amperage of the charger this might be bad advice.

good point.  thanks for pointing that out.

- erik

Re: [9fans] Brasil

[Charles Forsyth]

It was re-used


On 18 July 2014 18:30, Yoann Padioleau  wrote:

>  I thought it was the old name of plan9:
>
>  http://swtch.com/plan9history/?p=1999/1031;v=difflist
>
>
>  On Jul 17, 2014, at 6:27 PM, Shane Morris  wrote:
>
>  Hello 9fans,
>
>  I've been doing some research, and come across Brasil, which, if I've
> got this right, was a co-operating system minimal Inferno layer used on the
> Blue Gene/L project. Now, if I've got that wrong, please tell me...!
>
>  This interests me, of course, as I prepare to bring up my Parallella
> board (I still need a fan for it - tsk tsk). Is there any source for Brasil
> available to the public, as my Google searches isn't showing any repos (but
> I did get this:
> http://graverobbers.blogspot.com.au/2009/05/few-words-on-brasil.html
> )?
> I understand the project to the Blue Gene/L was many years ago, and all of
> the IBM references on their website seem to have disappeared in the interim.
>
>  Many thanks!
>
>  Shane.
>
>
>

Re: [9fans] Brasil

[Yoann Padioleau]

I thought it was the old name of plan9:

http://swtch.com/plan9history/?p=1999/1031;v=difflist


On Jul 17, 2014, at 6:27 PM, Shane Morris 
mailto:edgecombe...@gmail.com>> wrote:

Hello 9fans,

I've been doing some research, and come across Brasil, which, if I've got this 
right, was a co-operating system minimal Inferno layer used on the Blue Gene/L 
project. Now, if I've got that wrong, please tell me...!

This interests me, of course, as I prepare to bring up my Parallella board (I 
still need a fan for it - tsk tsk). Is there any source for Brasil available to 
the public, as my Google searches isn't showing any repos (but I did get this: 
http://graverobbers.blogspot.com.au/2009/05/few-words-on-brasil.html)?
 I understand the project to the Blue Gene/L was many years ago, and all of the 
IBM references on their website seem to have disappeared in the interim.

Many thanks!

Shane.

Re: [9fans] file server speed

[hiro]

> perhaps high-efficiency wall warts could make up much of the difference.
> picked at random (first link) ...
>
> http://www.amazon.com/Nokia-AC-10U-Micro-USB-Efficiency-Charger/dp/B00DP0TQLG
>

Given that the rpi has some weird power issues and without
specification of the amperage of the charger this might be bad advice.

Re: [9fans] Keeping 9pi up to date

[Richard Miller]

> Would a "replica/pull -v /dist/replica/network" result in the same system as 
> the last 9pi kit 
> (http://plan9.bell-labs.com/sources/contrib/miller/9pi.img.gz)?

Almost.  See http://9fans.net/archive/2014/02/131 for details.

Re: [9fans] Plan9 Sources Repository

[erik quanstrom]

> Yet: is there a source control system behind it?
> Would it be possible to check out directly from there?

there is nothing most folks would recognize as a distributed
revision control system.

the repo is sources itself.  history is through history(1).
you can "check out" code with cp(1), tar(1), mkfs(8); you can
keep up with the repo with replica(1).

patches are submitted via patch(1).

> If there is none, could it be that this contributes to the lack of 
> popularity and to the fragmentation of Plan9 (9front, 9atom, 9legacy, 
> PlanB, other plans...)?

i would think the "lack of popularity" can be most directly attributed
to the closed license in the early 90s, when there was an unfilled niche,
and linux was seriously lacking.

i starting doing something slightly different when il was pulled from
the distribution while i was in no position to stop using it.  it had nothing
to do with source control.

- erik

Re: [9fans] Plan9 Sources Repository

[cam]

> Yet: is there a source control system behind it?
> Would it be possible to check out directly from there?

for the bell-labs distribution, the filesystem itself keeps 
a daily record of the source tree.  you can access it with
9fs sourcesdump and the daily state of sources will be
in /n/sourcesdump.

> If there is none, could it be that this contributes to the lack of 
> popularity

9front and 9legacy both use mercurial as their revision
control systems.  9legacy keeps a mirror of the bell-labs
distribution in mercurial as well if that suits your needs.

9front's repo:

http://code.google.com/p/plan9front

9legacy's various repositories and mirrors:

https://hg.9grid.fr/

> and to the fragmentation of Plan9 (9front, 9atom, 9legacy, 
> PlanB, other plans...)?

the reason for the different distributions is really no 
different than the motivation for the different bsd or
linux distributions:  they each have their own goals
and purpose.

Re: [9fans] Plan9 Sources Repository

[Aram Hăvărneanu]

Sources is not kept up-to-date by volunteers, unless you mean
contrib, it is maintained by the Labs. Also, in a way, the sources
server *is* Plan 9, rather than being updated *with* Plan 9.

Plan 9 doesn't traditionally use version control. Rather, most
disk-based Plan 9 file servers offer some form of history in the
form of dumps or snapshots. 9fs sourcesdump will mount the sources
dump, and you can inspect daily changes starting around some 12
years ago using regular Plan 9 tools such as editors, yesterday(1)
and diffy(1).

History management is superior in Plan 9 compared to git and
mercurial. What git does better (at least according to some people),
is patch management. The Labs and 9atom use some patch management
technology best described in their manuals rather than on the mailing
list. 9front uses mercurial for patch management.

-- 
Aram Hăvărneanu

[9fans] Keeping 9pi up to date

[dante]

Dear Mr. Miller,

Would a "replica/pull -v /dist/replica/network" result in the same 
system as the last 9pi kit 
(http://plan9.bell-labs.com/sources/contrib/miller/9pi.img.gz)?


Thanks,
Dante

[9fans] Plan9 Sources Repository

[dante]

Dear 9Fans,

I see that Bell Labs offers a sources repository of Plan9, that is 
kindly kept up-to-date by volonteers (thanks!).


Yet: is there a source control system behind it?
Would it be possible to check out directly from there?

If there is none, could it be that this contributes to the lack of 
popularity and to the fragmentation of Plan9 (9front, 9atom, 9legacy, 
PlanB, other plans...)?


Kind Regards,
Dante

Re: [9fans] Brasil

[Oleksandr Iakovliev]

Good question, it looks interesting,
I also had intention to check inferno on parallela board


On 2014-07-18 03:27 , Shane Morris wrote:
> Hello 9fans,
>
> I've been doing some research, and come across Brasil, which, if I've
> got this right, was a co-operating system minimal Inferno layer used
> on the Blue Gene/L project. Now, if I've got that wrong, please tell
> me...!
>
> This interests me, of course, as I prepare to bring up my Parallella
> board (I still need a fan for it - tsk tsk). Is there any source for
> Brasil available to the public, as my Google searches isn't showing
> any repos (but I did get this:
> http://graverobbers.blogspot.com.au/2009/05/few-words-on-brasil.html)?
> I understand the project to the Blue Gene/L was many years ago, and
> all of the IBM references on their website seem to have disappeared in
> the interim.
>
> Many thanks!
>
> Shane.




signature.asc
Description: OpenPGP digital signature