Re: 9 Games of Go

It might be worth the effort to implement Go Text Protocol
(http://www.lysator.liu.se/~gunnar/gtp/), just in case you're having
trouble finding people to play with.

Anyway, nice work.

fhs

2009/8/31 Akshat Kumar <akumar <at> mail.nanosouffle.net>:
> With the hopes of playing Go amongst
> fellow Plan 9 users, I've written a little
> filesystem[1] which can currently be
> used for any two-player turn-based
> games.
>
> I'm currently working on Paurea's
> wonderful goban code, to implement
> support for reading from and writing to
> files, so that we have a working
> interface to use.
> I also have plans to add the same
> ability to Mirtchovski's port of GNU Go,
> so that the antisocial community can
> play amongst themselves (or oneself).
>
> The filesystem is meant to simulate
> a proper game server, through basic
> file and permissions operations.
>
> Creating a directory in the root of the fs

Re: 9 Games of Go

> It might be worth the effort to implement Go Text Protocol
> (http://www.lysator.liu.se/~gunnar/gtp/), just in case you're having
> trouble finding people to play with.

No, I'm going for world domination. Starting with the local Go group.

The fileserver is meant for Plan 9 communications, and is left open
to serve any interface that provides a two-player turn-based game.
This includes Go, Chess, Checkers, and whatever else. After the
rudimentary interface is provided by an application (i.e., a board
or an automated engine), the only thing required to make it
networked is to decide on a format and use it to read/write on
files served by the fs (and handle gid permissions, if one wants).
To this effect, I've added *no* Go primitives or specifications to
the filesystem, and don't intend to do so in the future.

I never found it interesting to play with random people on the
internet, anyway. This is at least a dreidel roll away from
being the roll of dice.

> Anyway, nice work.

Thanks,
ak

8c vlong bug

temporarly out of time on this one.  it appears
from the assembly output that 8c multiplies by
0 and not 1 when computing z a second time.
nonetheless, i haven't yet seen the problem.

#include <u.h>
#include <libc.h>

void
main(void)
{
	int three, one;
	uvlong twelve, z;

	one = 1;
	three = 3;
	twelve = 12;

	z = one*(twelve - three);
	print("z = %llud\n", z);

	z = (twelve - three) * one;
	print("z = %llud\n", z);

	exits(0);
}

output:

z = 9

Re: 8c vlong bug

if it's my fault i'll fix it. it did screw up mod in a subtle way but
that's been fixed.

brucee

On Tue, Sep 1, 2009 at 11:47 AM, erik quanstrom<quanstro <at> quanstro.net> wrote:
> temporarly out of time on this one.  it appears
> from the assembly output that 8c multiplies by
> 0 and not 1 when computing z a second time.
> nonetheless, i haven't yet seen the problem.
>
> #include <u.h>
> #include <libc.h>
>
> void
> main(void)
> {
>        int three, one;
>        uvlong twelve, z;
>
>        one = 1;
>        three = 3;
>        twelve = 12;
>
>        z = one*(twelve - three);
>        print("z = %llud\n", z);
>
>        z = (twelve - three) * one;
>        print("z = %llud\n", z);
>

Re: 8c vlong bug

> temporarly out of time on this one.  it appears
> from the assembly output that 8c multiplies by
> 0 and not 1 when computing z a second time.
> nonetheless, i haven't yet seen the problem.

not quite that simple.
it's a register allocation
(really register management) bug.

On Mon, Aug 31, 2009 at 6:51 PM, Bruce Ellis<bruce.ellis <at> gmail.com> wrote:
> if it's my fault i'll fix it. it did screw up mod in a subtle way but
> that's been fixed.

it looks like the cgen64 multiply case is
not managing the registers correctly
when AX is not where it expects.
more details for you:

int three = 3;
int one = 1;
uvlong twelve = 12;

/* ok */
uvlong
mul1(void)
{
	return one * (twelve - three);
}

TEXT	mul1+0(SB),0,$12

Re: 8c vlong bug

will fix.

On Tue, Sep 1, 2009 at 1:10 PM, Russ Cox<rsc <at> swtch.com> wrote:
>> temporarly out of time on this one.  it appears
>> from the assembly output that 8c multiplies by
>> 0 and not 1 when computing z a second time.
>> nonetheless, i haven't yet seen the problem.
>
> not quite that simple.
> it's a register allocation
> (really register management) bug.
>
> On Mon, Aug 31, 2009 at 6:51 PM, Bruce Ellis<bruce.ellis <at> gmail.com> wrote:
>> if it's my fault i'll fix it. it did screw up mod in a subtle way but
>> that's been fixed.
>
> it looks like the cgen64 multiply case is
> not managing the registers correctly
> when AX is not where it expects.
> more details for you:
>
> int three = 3;
> int one = 1;
> uvlong twelve = 12;
>
> /* ok */
> uvlong
> mul1(void)
> {
>        return one * (twelve - three);

lowest valid stack address

assuming no thread library, is there a way of
determining the lowest valid stack address
from userspace?  the purpose is to create a
test onstack() so that it can be asserted that
a given pointer is !onstack.  thread library
knows.

is it fair to assume that the stack can be up
to 256mb?  how does this generalize to 64 bits?

how bogus is this code, and why?

void
initbos(int x)
{
	uint m;
	uintptr p;

	p = (uintptr)&x;
	m = 1 << sizeof p*8 - 4;
	m -= 1;
	p &= ~m;
	print("%p\n", p);
}

uintptr	bos;

#define onstack(x)	((uintptr)(x) >= bos)
#define threadonstack(x)	/* thread library knows */

Re: lowest valid stack address

read /proc/$pid/segment

--
cinap

From: erik quanstrom <quanstro <at> quanstro.net>
Subject: [9fans] lowest valid stack address
Date: 2009-09-01 15:08:06 GMT

assuming no thread library, is there a way of
determining the lowest valid stack address
from userspace?  the purpose is to create a
test onstack() so that it can be asserted that
a given pointer is !onstack.  thread library
knows.

is it fair to assume that the stack can be up
to 256mb?  how does this generalize to 64 bits?

how bogus is this code, and why?

void
initbos(int x)
{
	uint m;

Re: lowest valid stack address

On Tue Sep  1 12:54:06 EDT 2009, cinap_lenrek <at> gmx.de wrote:

> read /proc/$pid/segment
> 

how do i know how low the stack segment can go?

- erik

Re: lowest valid stack address

On Tue Sep  1 12:56:41 EDT 2009, quanstro <at> quanstro.net wrote:
> On Tue Sep  1 12:54:06 EDT 2009, cinap_lenrek <at> gmx.de wrote:
> 
> > read /proc/$pid/segment
> 
> how do i know how low the stack segment can go?

i should have been more explicit.  it's not that useful to know
what the current stack allocation is.  it's more useful to know
what the lowest possible stack address could be.
knowing the exact minimum address of my process
doesn't tell me anything about other process' stacks
with which i share memory space.  the address in
question might be on another proc's stack.

i'm also worried that it would not be cheep enough to do
a system call ~50x per mailbox message to check the
sbrk or look at /proc/$pid/segment.  this would mean
500000-1m extra system calls just to open a mailbox.

i suppose that a function like malloctopaddr() would
do that without locking returns the last sbrk.

but i'd settle for the lowest stack address.

- erik