summaryrefslogtreecommitdiff
path: root/src/runtime/sys_windows_386.s
Commit message (Collapse)AuthorAgeFilesLines
* runtime: make time correctly update on WineEvgeniy Polyakov2017-04-251-1/+11
| | | | | | | | | | | | | | | | | | | | | Implemented low-level time system for windows on hardware (software), which does not support memory mapped _KSYSTEM_TIME page update. In particular this problem exists on Wine where _KSYSTEM_TIME only contains time at the start, and is never modified. On start we try to detect Wine and if it's so we fallback to GetSystemTimeAsFileTime() for current time and a monotonic timer based on QueryPerformanceCounter family of syscalls: https://msdn.microsoft.com/en-us/library/windows/desktop/dn553408(v=vs.85).aspx Fixes #18537 Change-Id: I269d22467ed9b0afb62056974d23e731b80c83ed Reviewed-on: https://go-review.googlesource.com/35710 Reviewed-by: Alex Brainman <alex.brainman@gmail.com> Run-TryBot: Alex Brainman <alex.brainman@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
* runtime: update assembly var names after monotonic time changesJosh Bleecher Snyder2017-02-211-3/+3
| | | | | | | | Change-Id: I721045120a4df41462c02252e2e5e8529ae2d694 Reviewed-on: https://go-review.googlesource.com/37303 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
* time: optimize Now on darwin, windowsRuss Cox2017-02-091-8/+96
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fetch both monotonic and wall time together when possible. Avoids skew and is cheaper. Also shave a few ns off in conversion in package time. Compared to current implementation (after monotonic changes): name old time/op new time/op delta Now 19.6ns ± 1% 9.7ns ± 1% -50.63% (p=0.000 n=41+49) darwin/amd64 Now 23.5ns ± 4% 10.6ns ± 5% -54.61% (p=0.000 n=30+28) windows/amd64 Now 54.5ns ± 5% 29.8ns ± 9% -45.40% (p=0.000 n=27+29) windows/386 More importantly, compared to Go 1.8: name old time/op new time/op delta Now 9.5ns ± 1% 9.7ns ± 1% +1.94% (p=0.000 n=41+49) darwin/amd64 Now 12.9ns ± 5% 10.6ns ± 5% -17.73% (p=0.000 n=30+28) windows/amd64 Now 15.3ns ± 5% 29.8ns ± 9% +94.36% (p=0.000 n=30+29) windows/386 This brings time.Now back in line with Go 1.8 on darwin/amd64 and windows/amd64. It's not obvious why windows/386 is still noticeably worse than Go 1.8, but it's better than before this CL. The windows/386 speed is not too important; the changes just keep the two architectures similar. Change-Id: If69b94970c8a1a57910a371ee91e0d4e82e46c5d Reviewed-on: https://go-review.googlesource.com/36428 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
* time: record monotonic clock reading in time.Now, for more accurate comparisonsRuss Cox2017-02-031-2/+2
| | | | | | | | | | | | | See https://golang.org/design/12914-monotonic for details. Fixes #12914. Change-Id: I80edc2e6c012b4ace7161c84cf067d444381a009 Reviewed-on: https://go-review.googlesource.com/36255 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Caleb Spare <cespare@gmail.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
* runtime, cmd/compile: rename memclr -> memclrNoHeapPointersAustin Clements2016-10-281-2/+2
| | | | | | | | | | | | | | | | | | | | Since barrier-less memclr is only safe in very narrow circumstances, this commit renames memclr to avoid accidentally calling memclr on typed memory. This can cause subtle, non-deterministic bugs, so it's worth some effort to prevent. In the near term, this will also prevent bugs creeping in from any concurrent CLs that add calls to memclr; if this happens, whichever patch hits master second will fail to compile. This also adds the other new memclr variants to the compiler's builtin.go to minimize the churn on that binary blob. We'll use these in future commits. Updates #17503. Change-Id: I00eead049f5bd35ca107ea525966831f3d1ed9ca Reviewed-on: https://go-review.googlesource.com/31369 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Rick Hudson <rlh@golang.org>
* runtime, syscall: use FP instead of SP for parametersMatthew Dempsky2016-09-301-2/+2
| | | | | | | | | | | | | | | | Consistently access function parameters using the FP pseudo-register instead of SP (e.g., x+0(FP) instead of x+4(SP) or x+8(SP), depending on register size). Two reasons: 1) doc/asm says the SP pseudo-register should use negative offsets in the range [-framesize, 0), and 2) cmd/vet only validates parameter offsets when indexed from the FP pseudo-register. No binary changes to the compiled object files for any of the affected package/OS/arch combinations. Change-Id: I0efc6079bc7519fcea588c114ec6a39b245d68b0 Reviewed-on: https://go-review.googlesource.com/30085 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* runtime: change osyield to use Windows SwitchToThreadAlex Brainman2016-04-041-4/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | It appears that windows osyield is just 15ms sleep on my computer (see benchmarks below). Replace NtWaitForSingleObject in osyield with SwitchToThread (as suggested by Dmitry). Also add issue #14790 related benchmarks, so we can track perfomance changes in CL 20834 and CL 20835 and beyond. Update #14790 benchmark old ns/op new ns/op delta BenchmarkChanToSyscallPing1ms 1953200 1953000 -0.01% BenchmarkChanToSyscallPing15ms 31562904 31248400 -1.00% BenchmarkSyscallToSyscallPing1ms 5247 4202 -19.92% BenchmarkSyscallToSyscallPing15ms 5260 4374 -16.84% BenchmarkChanToChanPing1ms 474 494 +4.22% BenchmarkChanToChanPing15ms 468 489 +4.49% BenchmarkOsYield1ms 980018 75.5 -99.99% BenchmarkOsYield15ms 15625200 75.8 -100.00% Change-Id: I1b4cc7caca784e2548ee3c846ca07ef152ebedce Reviewed-on: https://go-review.googlesource.com/21294 Run-TryBot: Alex Brainman <alex.brainman@gmail.com> Reviewed-by: Dmitry Vyukov <dvyukov@google.com> Run-TryBot: Dmitry Vyukov <dvyukov@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
* runtime: increase assumed stack size in externalthreadhandlerAustin Clements2016-01-071-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | On Windows, externalthreadhandler currently sets the assumed stack size for the profiler thread and the ctrlhandler threads to 8KB. The actual stack size is determined by the SizeOfStackReserve field in the binary set by the linker, which is currently at least 64KB (and typically 128KB). It turns out the profiler thread is running within a few words of the 8KB-(stack guard) bound set by externalthreadhandler. If it overflows this bound, morestack crashes unceremoniously with an access violation, which we then fail to handle, causing the whole process to exit without explanation. To avoid this problem and give us some breathing room, increase the assumed stack size in externalthreadhandler to 32KB (there's some unknown amount of stack already in use, so it's not safe to increase this all the way to the reserve size). We also document the relationships between externalthreadhandler and SizeOfStackReserve to make this more obvious in the future. Change-Id: I2f9f9c0892076d78e09827022ff0f2bedd9680a9 Reviewed-on: https://go-review.googlesource.com/18304 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Alex Brainman <alex.brainman@gmail.com> Reviewed-by: Minux Ma <minux@golang.org>
* runtime: really pass return value to Windows in externalthreadhandlerAlex Brainman2015-04-151-0/+2
| | | | | | | | | | | | | | | When Windows calls externalthreadhandler it expects to receive return value in AX. We don't set AX anywhere. Change that. Store ctrlhandler1 and profileloop1 return values into AX before returning from externalthreadhandler. Fixes #10215. Change-Id: Ied04542cc3ebe7d4a26660e970f9f78098143591 Reviewed-on: https://go-review.googlesource.com/8901 Reviewed-by: Minux Ma <minux@golang.org> Run-TryBot: Alex Brainman <alex.brainman@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
* [dev.cc] runtime: remove comma at the end of DIVL instruction (fixes windows ↵Alex Brainman2015-02-171-1/+1
| | | | | | | | build) Change-Id: Ia47e1e387acd30f30559d766aa6fca18cbb098f9 Reviewed-on: https://go-review.googlesource.com/5010 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* runtime: remove trailing empty arrays in structsKeith Randall2015-01-071-5/+5
| | | | | | | | | | | | | | | | | | The ones at the end of M and G are just used to compute their size for use in assembly. Generate the size explicitly. The one at the end of itab is variable-sized, and at least one. The ones at the end of interfacetype and uncommontype are not needed, as the preceding slice references them (the slice was originally added for use by reflect?). The one at the end of stackmap is already accessed correctly, and the runtime never allocates one. Update #9401 Change-Id: Ia75e3aaee38425f038c506868a17105bd64c712f Reviewed-on: https://go-review.googlesource.com/2420 Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
* Revert "liblink, cmd/ld, runtime: remove stackguard1"Russ Cox2015-01-051-2/+4
| | | | | | | | | | | | | | | | | This reverts commit ab0535ae3fb45ba734d47542cc4845f27f708d1b. I think it will remain useful to distinguish code that must run on a system stack from code that can run on either stack, even if that distinction is no longer based on the implementation language. That is, I expect to add a //go:systemstack comment that, in terms of the old implementation, tells the compiler, to pretend this function was written in C. Change-Id: I33d2ebb2f99ae12496484c6ec8ed07233d693275 Reviewed-on: https://go-review.googlesource.com/2275 Reviewed-by: Russ Cox <rsc@golang.org>
* liblink, cmd/ld, runtime: remove stackguard1Shenghou Ma2014-12-291-4/+2
| | | | | | | | | | | | | Now that we've removed all the C code in runtime and the C compilers, there is no need to have a separate stackguard field to check for C code on Go stack. Remove field g.stackguard1 and rename g.stackguard0 to g.stackguard. Adjust liblink and cmd/ld as necessary. Change-Id: I54e75db5a93d783e86af5ff1a6cd497d669d8d33 Reviewed-on: https://go-review.googlesource.com/2144 Reviewed-by: Keith Randall <khr@golang.org>
* [dev.cc] runtime: update sys_windows_386.s and sys_windows_amd64.s for Go ↵Alex Brainman2014-11-191-8/+8
| | | | | | | | | conversion LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/176970043
* [dev.cc] all: merge dev.power64 (7667e41f3ced) into dev.ccRuss Cox2014-11-141-6/+6
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is to reduce the delta between dev.cc and dev.garbage to just garbage collector changes. These are the files that had merge conflicts and have been edited by hand: malloc.go mem_linux.go mgc.go os1_linux.go proc1.go panic1.go runtime1.go LGTM=austin R=austin CC=golang-codereviews https://golang.org/cl/174180043
| * [dev.power64] cmd/5a, cmd/6a, cmd/8a, cmd/9a: make labels function-scopedRuss Cox2014-10-281-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I removed support for jumping between functions years ago, as part of doing the instruction layout for each function separately. Given that, it makes sense to treat labels as function-scoped. This lets each function have its own 'loop' label, for example. Makes the assembly much cleaner and removes the last reason anyone would reach for the 123(PC) form instead. Note that this is on the dev.power64 branch, but it changes all the assemblers. The change will ship in Go 1.5 (perhaps after being ported into the new assembler). Came up as part of CL 167730043. LGTM=r R=r CC=austin, dave, golang-codereviews, minux https://golang.org/cl/159670043
* | [dev.cc] runtime: convert assembly files for C to Go transitionRuss Cox2014-11-111-1/+2
|/ | | | | | | | | | | | | | | | | | | | | The main change is that #include "zasm_GOOS_GOARCH.h" is now #include "go_asm.h" and/or #include "go_tls.h". Also, because C StackGuard is now Go _StackGuard, the assembly name changes from const_StackGuard to const__StackGuard. In asm_$GOARCH.s, add new function getg, formerly implemented in C. The renamed atomics now have Go wrappers, to get escape analysis annotations right. Those wrappers are in CL 174860043. LGTM=r, aram R=r, aram CC=austin, dvyukov, golang-codereviews, iant, khr https://golang.org/cl/168510043
* runtime: handle all windows exception (second attempt)Alex Brainman2014-10-151-2/+16
| | | | | | | | | | | | | includes undo of 22318cd31d7d and also: - always use SetUnhandledExceptionFilter on windows-386; - crash when receive EXCEPTION_BREAKPOINT in exception handler. Fixes #8006. LGTM=rsc R=golang-codereviews, rsc CC=golang-codereviews https://golang.org/cl/155360043
* undo CL 145150043 / 8b3d26697b8dAlex Brainman2014-10-091-16/+2
| | | | | | | | | | | | | | | | | | | | | | | That was complete failure - builders are broken, but original cl worked fine on my system. I will need access to builders to test this change properly. ««« original CL description runtime: handle all windows exception Fixes #8006. LGTM=rsc R=golang-codereviews, rsc CC=golang-codereviews https://golang.org/cl/145150043 »»» TBR=rsc R=golang-codereviews CC=golang-codereviews https://golang.org/cl/154180043
* runtime: handle all windows exceptionAlex Brainman2014-10-091-2/+16
| | | | | | | | | Fixes #8006. LGTM=rsc R=golang-codereviews, rsc CC=golang-codereviews https://golang.org/cl/145150043
* runtime: more NOPTRRuss Cox2014-09-241-1/+1
| | | | | | | | | | Fixes linux builds (_vdso); may fix others. I can at least cross-compile cmd/go for every implemented system now. TBR=iant CC=golang-codereviews https://golang.org/cl/142630043
* runtime: fix windows/386 buildRuss Cox2014-09-091-1/+1
| | | | | | | | | | | | | | The difference between the old and the new (from earlier) code is that we set stackguard = stack.lo + StackGuard, while the old code set stackguard = stack.lo. That 512 bytes appears to be the difference between the profileloop function running and not running. We don't know how big the system stack is, but it is likely MUCH bigger than 4k. Give Go/C 8k. TBR=iant CC=golang-codereviews https://golang.org/cl/140440044
* runtime: fix build failures after CL 137410043Russ Cox2014-09-091-5/+11
| | | | | | | | No promise about correctness, but they do build. TBR=khr CC=golang-codereviews https://golang.org/cl/143720043
* runtime: undo stray edit from CL 140380043Russ Cox2014-09-081-1/+1
| | | | | | | | Was having serious editor problems on Windows. TBR=brainman, iant CC=golang-codereviews https://golang.org/cl/137370043
* runtime: run sighandler on g0 stack on windowsRuss Cox2014-09-081-7/+40
| | | | | | | | | | | | | | | | | | | | | | The sighander has been run at the bottom of the currently executing goroutine stack, but it's in C, and we don't want C on our ordinary goroutine stacks. Worse, it does a lot of stuff, and it might need more stack space. There is scary code in traceback_windows.go that talks about stack splits during sighandler. Moving sighandler to g0 will eliminate the possibility of stack splits and such, and then we can delete traceback_windows.go entirely. Win win. On the builder, all.bat passes with GOARCH=amd64 and all.bat gets most of the way with GOARCH=386 except for a DLL-loading test that I think is unrelated. Fixes windows build. TBR=brainman, iant CC=golang-codereviews https://golang.org/cl/140380043
* build: move package sources from src/pkg to srcRuss Cox2014-09-081-0/+380
Preparation was in CL 134570043. This CL contains only the effect of 'hg mv src/pkg/* src'. For more about the move, see golang.org/s/go14nopkg.
View Lorry Controller Status