[9fans] plan9/arm in Go 1.7? (was: rc exec error behaviour)

[Skip Tavakkolian]

Russ has started the planning for Go 1.7 on #godev.  Would it be too
optimistic to expect plan9/arm in that release?

>> Richard Miller is contributing a lot of great stuff to Go for plan9/arm.
> 
> Thank you, but mostly I've just updated and titivated the previous
> work from Lucio and Gorka, to the state where it should pass the
> codereview and does pass all the go1.6 tests (with *ncpu=1).
> 
> For multicore I am still chasing down some bugs in Plan 9 (and not
> only on arm) which seem to be flushed out by the particularly brutal
> go test suite.

Re: [9fans] plan9/arm in Go 1.7? (was: rc exec error behaviour)

[David du Colombier]

> Russ has started the planning for Go 1.7 on #godev.  Would it be too
> optimistic to expect plan9/arm in that release?

Yes. Richard has already submitted his CLs for review.

-- 
David du Colombier

[9fans] FP register usage in Plan9 assembler

[Giacomo Tesio]

I'm studying the 9front's amd64 kernel, and I'm pretty new to assembler
programming, so sorry if my question is too dumb...

I cannot understand the FP pseudo register usage.
The cpuid function, for example, is implemented as

/*
 * The CPUID instruction is always supported on the amd64.
 */
TEXT cpuid(SB), $-4
MOVLRARG, AX/* function in AX */
CPUID

MOVQinfo+8(FP), BP
MOVLAX, 0(BP)
MOVLBX, 4(BP)
MOVLCX, 8(BP)
MOVLDX, 12(BP)
RET

What I miss is where "info" comes from. I cannot

Apparently the GAS equivalent is:

.align 4
.globl cpuid
cpuid:
mov%ebp,%eax
cpuid
mov0x10(%rsp),%rbp
mov%eax,0x0(%rbp)
mov%ebx,0x4(%rbp)
mov%ecx,0x8(%rbp)
mov%edx,0xc(%rbp)
retq

Thus apparently info+8(FP) becomes 0x10(%rsp)
Why? I know that FP is a pseudo register, but shouldn't it be different
from SP?

And why info's value is 8? Is it the pointer size?

Another example:

TEXT insb(SB), 1, $-4
MOVLRARG, DX/* MOVLport+0(FP), DX */
MOVQaddress+8(FP), DI
MOVLcount+16(FP), CX
CLD
REP;INSB
RET

should be equivalent to

.align 4
.globl insb
insb:
mov%ebp,%edx
mov0x10(%rsp),%rdi
mov0x18(%rsp),%ecx
cld
rep insb
retq

Again I cannot find a definition of address and count, but both seem to be
be valued as 8, why?


Giacomo

Re: [9fans] FP register usage in Plan9 assembler

[Giacomo Tesio]

Thanks for the explainations!

I did read in the Pike's paper about the syntax name+offset(FP), but I did
understood that name had to be a symbol already defined, and I was looking
for it in the c code. Sorry for the noise!

This led me to another question, however: I've read before that the plan9
compilers use the stack for va_list, but here the assembler is using it
also for explicit parameters, right?

Is it correct to say that this means that the Plan9 compiler suite *never*
follows the sysV calling convention documented at section 3.2.3 of AMD64
ABI http://www.x86-64.org/documentation/abi.pdf and always pushes
parameters to the stack?


Giacomo



2016-02-01 23:48 GMT+01:00 :

> FP is a translated to a varying offset to SP depending on where in the
> program
> you are. arguments on the stack are padded to 8 bytes on amd64, the first
> argument
> is not passed on the stack on function entry, but passed in BP register
> (RARG is an
> alias for that), however the slot on the stack for first arg is still
> reserved
> so we have a save place to splill it. so 0(FP) is first function argument
> on the
> stack, 8(FP) second argument 16(FP) third ect...
>
> --
> cinap
>
>

Re: [9fans] FP register usage in Plan9 assembler

[Charles Forsyth]

On 1 February 2016 at 16:47, Giacomo Tesio  wrote:

> MOVQinfo+8(FP), BP
> MOVLAX, 0(BP)
> MOVLBX, 4(BP)
> MOVLCX, 8(BP)
> MOVLDX, 12(BP)
> RET
>
> What I miss is where "info" comes from.
>

the syntax name+offset(FP) defines name as the given offset from the
virtual frame pointer.
The actual offset in machine code is set by the loader (8l, 6l, etc.),
after taking account of the save area size, for example.
The name is stored in a symbol table mainly for use by the debugger.

Re: [9fans] rc exec error behaviour

[lucio]

> Thank you, but mostly I've just updated and titivated the previous
> work from Lucio and Gorka, to the state where it should pass the
> codereview and does pass all the go1.6 tests (with *ncpu=1).

I need to point out that I really added nothing other than a minute
amount of coordination at the time and in retrospect even that had a
very limited effect.  Gorka did the great work and I'm very pleased
that Richard picked it up and turned it into something I believe
(hope? wish?) will be with us for a while.

I wish I could share some of the glory, but I really do not deserve it
:-)

Here's a toast to all those who make my daily Plan 9 experiences a
pleasure.  Thank you all!

Lucio.

[9fans] Fwd: lib9p: Add clunk callback to Srv struct

[Tiago Natel]

Someone here can help me?

-- Forwarded message --
From: Tiago Natel 
Date: 2016-02-01 19:17 GMT-02:00
Subject: lib9p: Add clunk callback to Srv struct
To: 9fr...@9front.org


Hello folks,

Is there a reason why lib9p doesn't have a clunk function pointer in Srv
struct?

I have a file server project using Srv and I want to know when no one
client have a specific file opened.

One way that I was able to get this working was forking 9front and adding a
clunk callback to Srv structure. See the commit below:

https://bitbucket.org/tiago4orion/plan9front/commits/5e1141f0a4aa98310cb0e2382c5c78c60fe73b4f

My project usage of the clunk routine is here:
https://bitbucket.org/tiago4orion/dchan/src/60dc3e45eb28c8a8289c177680120ef7f44e0925/fs.c?fileviewer=file-view-default#fs.c-680

This makes sense? Or is there better ways to achieve this?
And if that makes sense, it can go upstream?

Thanks.

Re: [9fans] FP register usage in Plan9 assembler

[cinap_lenrek]

FP is a translated to a varying offset to SP depending on where in the program
you are. arguments on the stack are padded to 8 bytes on amd64, the first 
argument
is not passed on the stack on function entry, but passed in BP register (RARG 
is an
alias for that), however the slot on the stack for first arg is still reserved
so we have a save place to splill it. so 0(FP) is first function argument on the
stack, 8(FP) second argument 16(FP) third ect...

--
cinap

Re: [9fans] Fwd: lib9p: Add clunk callback to Srv struct

[cinap_lenrek]

> Is there a reason why lib9p doesn't have a clunk function pointer in Srv 
> struct?

what about Srv.destroyfid()?

  Destroyfid
   When a Fid's reference count drops to zero (i.e., it
   has been clunked and there are no outstanding requests
   referring to it), destroyfid is called to allow the
   program to dispose of the fid->aux pointer.

--
cinap

Re: [9fans] Fwd: lib9p: Add clunk callback to Srv struct

[Skip Tavakkolian]

> I have a file server project using Srv and I want to know when no one
> client have a specific file opened.

i believe since you're using alloctree and passing in the destroy function, you 
don't need it. 

Re: [9fans] rc exec error behaviour

[Prof Brucee]

Cinap assured me that go works on 9front. Please send a wish list. Here
docs in functions are on it. Exec was the ball buster.
On 02/02/2016 8:53 AM,  wrote:

> > Thank you, but mostly I've just updated and titivated the previous
> > work from Lucio and Gorka, to the state where it should pass the
> > codereview and does pass all the go1.6 tests (with *ncpu=1).
>
> I need to point out that I really added nothing other than a minute
> amount of coordination at the time and in retrospect even that had a
> very limited effect.  Gorka did the great work and I'm very pleased
> that Richard picked it up and turned it into something I believe
> (hope? wish?) will be with us for a while.
>
> I wish I could share some of the glory, but I really do not deserve it
> :-)
>
> Here's a toast to all those who make my daily Plan 9 experiences a
> pleasure.  Thank you all!
>
> Lucio.
>
>
>

Re: [9fans] FP register usage in Plan9 assembler

[Charles Forsyth]

On 1 February 2016 at 23:34, Giacomo Tesio  wrote:

>
> Is it correct to say that this means that the Plan9 compiler suite *never*
> follows the sysV calling convention documented at section 3.2.3 of AMD64
> ABI http://www.x86-64.org/documentation/abi.pdf and always pushes
> parameters to the stack?


On amd64, the first parameter, if an integer, is passed in RARG, which is
actually BP.
The RISC machines generally pass the first parameter, if an integer, in a
register.

In general, the compiler suite never follows conventions prescribed by
apparent maniacs.
In particular, varargs/stdargs should (in 2000, let alone 2016) be really
easy: lay down the ... parameters on the stack as an array in memory.
Done. Instead ABIs give pages of filth that try to work out where things
are for the va_x macro calls,
because the ABI insists on following the same calling convention
for vararg/stdarg functions as might be used for other functions with fixed
parameters: parameter passing in registers, special rules for structs,
special rules for structs that fit in the parameter registers, special
rules for floating-point values. Absurd.

Re: [9fans] FP register usage in Plan9 assembler

[Giacomo Tesio]

I kinda agree, but I'm too incompetent in the matter. :-)

However, I was simply asking if, on amd64, kencc uses the 6 registers that
the abi deserves to the parameters.
As far as I've understood only BP is used (for the first argument, if
integer).

Can you confirm?



Giacomo

2016-02-02 1:36 GMT+01:00 Charles Forsyth :

>
> On 1 February 2016 at 23:34, Giacomo Tesio  wrote:
>
>>
>> Is it correct to say that this means that the Plan9 compiler suite
>> *never* follows the sysV calling convention documented at section 3.2.3 of
>> AMD64 ABI http://www.x86-64.org/documentation/abi.pdf and always pushes
>> parameters to the stack?
>
>
> On amd64, the first parameter, if an integer, is passed in RARG, which is
> actually BP.
> The RISC machines generally pass the first parameter, if an integer, in a
> register.
>
> In general, the compiler suite never follows conventions prescribed by
> apparent maniacs.
> In particular, varargs/stdargs should (in 2000, let alone 2016) be really
> easy: lay down the ... parameters on the stack as an array in memory.
> Done. Instead ABIs give pages of filth that try to work out where things
> are for the va_x macro calls,
> because the ABI insists on following the same calling convention
> for vararg/stdarg functions as might be used for other functions with
> fixed parameters: parameter passing in registers, special rules for
> structs, special rules for structs that fit in the parameter registers,
> special rules for floating-point values. Absurd.
>

Re: [9fans] rc exec error behaviour

[Richard Miller]

> Richard Miller is contributing a lot of great stuff to Go for plan9/arm.

Thank you, but mostly I've just updated and titivated the previous
work from Lucio and Gorka, to the state where it should pass the
codereview and does pass all the go1.6 tests (with *ncpu=1).

For multicore I am still chasing down some bugs in Plan 9 (and not
only on arm) which seem to be flushed out by the particularly brutal
go test suite.

Re: [9fans] rc exec error behaviour

[Lyndon Nerenberg]

> On Jan 31, 2016, at 8:06 PM, erik quanstrom  wrote:
> 
> i don't believe the offer was made with a straight face.

But perhaps with a bent compiler.

Re: [9fans] rc exec error behaviour

[Lyndon Nerenberg]

> On Feb 1, 2016, at 8:21 PM, Prof Brucee  wrote:
> 
> Every time I bend something it breaks.

I remember the "where's Bruce" from the ... whereever the hell it was Plan9 
workshop video.

Re: [9fans] rc exec error behaviour

[Prof Brucee]

Every time I bend something it breaks.
On 02/02/2016 3:18 PM, "Lyndon Nerenberg"  wrote:

>
> > On Jan 31, 2016, at 8:06 PM, erik quanstrom 
> wrote:
> >
> > i don't believe the offer was made with a straight face.
>
> But perhaps with a bent compiler.
>
>