qbit/go
1
0
Fork 0
mirror of https://github.com/golang/go synced 2024-11-19 16:34:49 -07:00
Code Releases Activity
d16a2ad09b
go/src/pkg/runtime/memclr_plan9_386.s

52 lines
828 B
ArmAsm
Raw Normal View History

runtime: use unoptimized memmove and memclr on Plan 9 On Plan 9, the kernel disallows the use of floating point instructions while handling a note. Previously, we worked around this by using a simple loop in place of memmove. When I added that work-around, I verified that all paths from the note handler didn't end up calling memmove. Now that memclr is using SSE instructions, the same process will have to be done again. Instead of doing that, however, this CL just punts and uses unoptimized functions everywhere on Plan 9. LGTM=rsc R=rsc, 0intro CC=golang-codereviews https://golang.org/cl/73830044
2014-03-12 19:12:25 -06:00
// Copyright 2014 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
#include "../../cmd/ld/textflag.h"
// void runtime·memclr(void*, uintptr)
TEXT runtime·memclr(SB), NOSPLIT, $0-8
MOVL ptr+0(FP), DI
MOVL n+4(FP), BX
XORL AX, AX
clr_tail:
TESTL BX, BX
JEQ clr_0
CMPL BX, $2
JBE clr_1or2
CMPL BX, $4
JBE clr_3or4
CMPL BX, $8
JBE clr_5through8
CMPL BX, $16
JBE clr_9through16
MOVL BX, CX
SHRL $2, CX
REP
STOSL
ANDL $3, BX
JNE clr_tail
RET
clr_1or2:
MOVB AX, (DI)
MOVB AX, -1(DI)(BX*1)
runtime: prevent pointless jmp in amd64 and 386 memmove 6a and 8a rearrange memmove such that the fallthrough from move_1or2 to move_0 ends up being a JMP to a RET. Insert an explicit RET to prevent such silliness. Do the same for memclr as prophylaxis. benchmark old ns/op new ns/op delta BenchmarkMemmove1 4.59 4.13 -10.02% BenchmarkMemmove2 4.58 4.13 -9.83% LGTM=khr R=golang-codereviews, dvyukov, minux, ruiu, bradfitz, khr CC=golang-codereviews https://golang.org/cl/120930043
2014-08-01 07:21:08 -06:00
RET
runtime: use unoptimized memmove and memclr on Plan 9 On Plan 9, the kernel disallows the use of floating point instructions while handling a note. Previously, we worked around this by using a simple loop in place of memmove. When I added that work-around, I verified that all paths from the note handler didn't end up calling memmove. Now that memclr is using SSE instructions, the same process will have to be done again. Instead of doing that, however, this CL just punts and uses unoptimized functions everywhere on Plan 9. LGTM=rsc R=rsc, 0intro CC=golang-codereviews https://golang.org/cl/73830044
2014-03-12 19:12:25 -06:00
clr_0:
RET
clr_3or4:
MOVW AX, (DI)
MOVW AX, -2(DI)(BX*1)
RET
clr_5through8:
MOVL AX, (DI)
MOVL AX, -4(DI)(BX*1)
RET
clr_9through16:
MOVL AX, (DI)
MOVL AX, 4(DI)
MOVL AX, -8(DI)(BX*1)
MOVL AX, -4(DI)(BX*1)
RET
Copy Permalink