[9fans] 9vx and Go

[l***@proxima.alt.za]

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

[David du Colombier]

Post by l***@proxima.alt.za
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.

[l***@proxima.alt.za]

Post by David du Colombier
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

[l***@proxima.alt.za]

Post by David du Colombier
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

[Anthony Martin]

Post by l***@proxima.alt.za

Post by David du Colombier
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

[Charles Forsyth]

MOVQ isn't a 32-bit instruction.

Post by Anthony Martin
There's also a few instructions (MOVQ, EMMS, etc.)

[Anthony Martin]

Post by Charles Forsyth
MOVQ isn't a 32-bit instruction.

It is if you're using MMX registers.

Anthony

[erik quanstrom]

Post by Anthony Martin

Post by Charles Forsyth
MOVQ isn't a 32-bit instruction.

It is if you're using MMX registers.

does 8g default to using mmx?

- erik

[Anthony Martin]

Post by erik quanstrom

Post by Anthony Martin

Post by Charles Forsyth
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

[erik quanstrom]

Post by Anthony Martin
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

[Anthony Martin]

Post by erik quanstrom

Post by Anthony Martin
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

[Charles Forsyth]

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

Post by Anthony Martin
It is if you're using MMX registers.