[9fans] 9vx and Go

[9fans] 9vx and Go

[lucio]

Trying to execute Go programs in 9vx suggests that somehow the new
syscalls required by the Go runtime are not supported.  There are a
few possible ways in which my installation is at fault, but before I
dig deeper (or ask different questions) I want to know that the
problem is not in 9vx itself.

If I need to update 9vx in some way, it is definitely worth my while
to do so.

++L

Re: [9fans] 9vx and Go

[David du Colombier]

> Trying to execute Go programs in 9vx suggests that somehow the new
> syscalls required by the Go runtime are not supported.  There are a
> few possible ways in which my installation is at fault, but before I
> dig deeper (or ask different questions) I want to know that the
> problem is not in 9vx itself.
>
> If I need to update 9vx in some way, it is definitely worth my while
> to do so.

Yes, the tsemacquire syscall is not currently implemented in 9vx.

If you plan to work on vx32, please use the following
repository, since it should contain the most recent work.

https://bitbucket.org/0intro/vx32

You could send patches directly to myself since Ron Minnich
handed the repository off to me.

--
David du Colombier

Re: [9fans] 9vx and Go

[lucio]

> If you plan to work on vx32, please use the following
> repository, since it should contain the most recent work.
>
> https://bitbucket.org/0intro/vx32
>
> You could send patches directly to myself since Ron Minnich
> handed the repository off to me.

Will do...

++L

Re: [9fans] 9vx and Go

[lucio]

> Yes, the tsemacquire syscall is not currently implemented in 9vx.

The "ticks" field is also not present in the mach structure, so adding
tsemacquire isn't trivial.  I was hoping to get away with just adding
the field, but if the comment is correct, I need at minimum to add
code to keep the ticks up to date and I can't seem to find model code
in Plan 9 to do it.  I guess I'm drowning...

++L

Re: [9fans] 9vx and Go

[Anthony Martin]

lucio@proxima.alt.za once said:
> > Yes, the tsemacquire syscall is not currently implemented in 9vx.
>
> The "ticks" field is also not present in the mach structure, so adding
> tsemacquire isn't trivial.  I was hoping to get away with just adding
> the field, but if the comment is correct, I need at minimum to add
> code to keep the ticks up to date and I can't seem to find model code
> in Plan 9 to do it.  I guess I'm drowning...

I have a few patches to support Go in my vx32 tree.
I've made lots of other changes so it might take me
a while to get a clean patch to David.

For tsemacquire, you can just s/m->ticks/msec()/.

There's also a few instructions (MOVQ, EMMS, etc.)
that have to be added to libvx32/emu.c since the Go
runtime and standard library use them.

Cheers,
  Anthony

Re: [9fans] 9vx and Go

[Charles Forsyth]

MOVQ isn't a 32-bit instruction.

On 10 December 2012 16:42, Anthony Martin <ality@pbrane.org> wrote:
> There's also a few instructions (MOVQ, EMMS, etc.)

Re: [9fans] 9vx and Go

[Anthony Martin]

Charles Forsyth <charles.forsyth@gmail.com> once said:
> MOVQ isn't a 32-bit instruction.

It is if you're using MMX registers.

  Anthony

Re: [9fans] 9vx and Go

[erik quanstrom]

On Mon Dec 10 19:11:39 EST 2012, ality@pbrane.org wrote:
> Charles Forsyth <charles.forsyth@gmail.com> once said:
> > MOVQ isn't a 32-bit instruction.
>
> It is if you're using MMX registers.

does 8g default to using mmx?

- erik

Re: [9fans] 9vx and Go

[Anthony Martin]

erik quanstrom <quanstro@quanstro.net> once said:
> On Mon Dec 10 19:11:39 EST 2012, ality@pbrane.org wrote:
> > Charles Forsyth <charles.forsyth@gmail.com> once said:
> > > MOVQ isn't a 32-bit instruction.
> >
> > It is if you're using MMX registers.
>
> does 8g default to using mmx?

No. They're written using BYTE instructions where needed.

Currently 8g will only generate 387 style fp code but the
is to eventually use SSE. See http://golang.org/issue/3912.

  Anthony

Re: [9fans] 9vx and Go

[erik quanstrom]

> No. They're written using BYTE instructions where needed.
>
> Currently 8g will only generate 387 style fp code but the
> is to eventually use SSE. See http://golang.org/issue/3912.
>

that's not what i read.  i read that it's going to be a compile-time
option.  surely they're not sneaking xmm in the side door.

- erik

Re: [9fans] 9vx and Go

[Anthony Martin]

erik quanstrom <quanstro@quanstro.net> once said:
> > No. They're written using BYTE instructions where needed.
> >
> > Currently 8g will only generate 387 style fp code but the
> > is to eventually use SSE. See http://golang.org/issue/3912.
> >
>
> that's not what i read.  i read that it's going to be a compile-time
> option.  surely they're not sneaking xmm in the side door.

Sort of. The plan is to use SSE by default but use an
environment variable (and compiler flag) to disable it.

This is how it works on ARM for different ABIs.
You set GOARM=5 or whatever and the compiler and
runtime won't use anything after that revision.

  Anthony

Re: [9fans] 9vx and Go

[Charles Forsyth]

oh no, not MMX. SSE/SSE2 surely (ie, XMM)?

On 11 December 2012 00:10, Anthony Martin <ality@pbrane.org> wrote:
> It is if you're using MMX registers.