code review 15760044: runtime: assembly and system calls for Native Client x86-64

runtime: assembly and system calls for Native Client x86-64

See golang.org/s/go13nacl for design overview.

This CL is publicly visible but not CC'ed to golang-dev,
to avoid distracting from the preparation of the Go 1.2
release.

This CL and the others will be checked into my rsc-go13nacl
clone repo for now, and I will send CLs against the main
repo early in the Go 1.3 development.

[adg, 2013-11-05 04:37:43]

https://codereview.appspot.com/15760044/diff/160001/src/pkg/runtime/sys_nacl_...
File src/pkg/runtime/sys_nacl_amd64p32.s (right):

https://codereview.appspot.com/15760044/diff/160001/src/pkg/runtime/sys_nacl_...
src/pkg/runtime/sys_nacl_amd64p32.s:58: MOVL arg1+0(FP), DI
add a comment:
// only do timedwrite for fds 1 and 2

https://codereview.appspot.com/15760044/diff/160001/src/pkg/runtime/sys_nacl_...
src/pkg/runtime/sys_nacl_amd64p32.s:71: timedwrite:
I've tried to use the term "playback" to describe this feature (that's where
"PB" comes from). maybe name this label "playbackwrite" ?

[rsc, 2013-11-11 14:50:31]

Hello adg@golang.org,

I'd like you to review this change to
https://code.google.com/r/rsc-go13nacl

[rsc, 2013-11-11 14:50:38]

*** Submitted as 436bb084caed ***

runtime: assembly and system calls for Native Client x86-64

See golang.org/s/go13nacl for design overview.

This CL is publicly visible but not CC'ed to golang-dev,
to avoid distracting from the preparation of the Go 1.2
release.

This CL and the others will be checked into my rsc-go13nacl
clone repo for now, and I will send CLs against the main
repo early in the Go 1.3 development.

R=adg
https://codereview.appspot.com/15760044

[adg, 2013-11-12 05:08:32]

https://codereview.appspot.com/15760044/diff/200001/src/pkg/runtime/sys_nacl_...
File src/pkg/runtime/sys_nacl_amd64p32.s (right):

https://codereview.appspot.com/15760044/diff/200001/src/pkg/runtime/sys_nacl_...
src/pkg/runtime/sys_nacl_amd64p32.s:71: timedwrite:
Should there be a per-fd lock held between here and RET?
Concurrent writes could interleave playback headers with data, creating a
corrupted playback feed and mysterious errors, as users typically have no idea
of the trickery that makes this possible.

[rsc, 2013-11-12 13:50:36]

https://codereview.appspot.com/15760044/diff/200001/src/pkg/runtime/sys_nacl_...
File src/pkg/runtime/sys_nacl_amd64p32.s (right):

https://codereview.appspot.com/15760044/diff/200001/src/pkg/runtime/sys_nacl_...
src/pkg/runtime/sys_nacl_amd64p32.s:71: timedwrite:
On 2013/11/12 05:08:32, adg wrote:
> Should there be a per-fd lock held between here and RET?
> Concurrent writes could interleave playback headers with data, creating a
> corrupted playback feed and mysterious errors, as users typically have no idea
> of the trickery that makes this possible.

Yes, and there is. The next four lines are a simple spin lock looping until
runtime.writelock can be acquired (via XCHGL). The unlock is the MOVL $0 at the
bottom just before RET. It's just one lock, not one per fd.

I forgot to make the changes you wanted about renaming timedwrite. I'll send a
CL that does that and adds more comments.