diff --git a/doc/gccgo_contribute.html b/doc/gccgo_contribute.html index cab6967f369..8eeb3a5c5cf 100644 --- a/doc/gccgo_contribute.html +++ b/doc/gccgo_contribute.html @@ -45,7 +45,7 @@ a gcc-interface subdirectory.

-The runtime library for gccgo is mostly the same as the +The run-time library for gccgo is mostly the same as the library in the main Go repository. The library code in the Go repository is periodically copied into the gofrontend and the gcc diff --git a/doc/gccgo_install.html b/doc/gccgo_install.html index 2ab6dcdae9e..159fab7bb5b 100644 --- a/doc/gccgo_install.html +++ b/doc/gccgo_install.html @@ -116,7 +116,7 @@ gccgo -o file file.o

To run the resulting file, you will need to tell the program where to -find the Go runtime library. This can be done either by setting +find the compiled Go packages. This can be done either by setting LD_LIBRARY_PATH in your environment: 

diff --git a/doc/go_faq.html b/doc/go_faq.html
index 6258f5808b8..0d5a6000ca0 100644
--- a/doc/go_faq.html
+++ b/doc/go_faq.html
@@ -730,7 +730,7 @@ Why doesn't my multi-goroutine program use multiple CPUs?
 
 

 Under the gc compilers you must set GOMAXPROCS to allow the
-runtime to utilise more than one OS thread. Under gccgo an OS
+run-time support to utilise more than one OS thread. Under gccgo an OS
 thread will be created for each goroutine, and GOMAXPROCS is
 effectively equal to the number of running goroutines.  
 

@@ -738,7 +738,7 @@ effectively equal to the number of running goroutines.
 

 Programs that perform concurrent computation should benefit from an increase in
 GOMAXPROCS. (See the runtime package
+href="http://golang.org/pkg/runtime/#GOMAXPROCS">runtime package's
 documentation.)
 

 
@@ -759,8 +759,8 @@ penalty involved in sending data between threads.
 

 
 

-The Go runtime's scheduler is not as good as it needs to be. In future, it
-should recognise such cases and optimize its use of OS threads. For now,
+Go's goroutine scheduler is not as good as it needs to be. In future, it
+should recognize such cases and optimize its use of OS threads. For now,
 GOMAXPROCS should be set on a per-application basis.
 

 
@@ -942,13 +942,13 @@ parser are already available in /pkg/go.)
 We also considered using LLVM for 6g but we felt it was too large and
 slow to meet our performance goals.
 
-

-How is the runtime implemented?

+

+How is the run-time support implemented?

 
 

-Again due to bootstrapping issues, the runtime is mostly in C (with a
+Again due to bootstrapping issues, the run-time code is mostly in C (with a
 tiny bit of assembler) although Go is capable of implementing most of
-it now. Gccgo's runtime uses glibc.
+it now. Gccgo's run-time support uses glibc.
 Gc uses a custom library, to keep the footprint under
 control; it is
 compiled with a version of the Plan 9 C compiler that supports
@@ -968,7 +968,7 @@ type checks, reflection, and even panic-time stack traces.
 

 A trivial C "hello, world" program compiled and linked statically using gcc
 on Linux is around 750 kB.  An equivalent Go program is around 1.8 MB, but
-that includes a more powerful runtime.  We believe that with some effort
+that includes more powerful run-time support.  We believe that with some effort
 the size of Go binaries can be reduced.
 
 
Performance

diff --git a/doc/go_for_cpp_programmers.html b/doc/go_for_cpp_programmers.html
index 608ab147b33..7168f1d057d 100644
--- a/doc/go_for_cpp_programmers.html
+++ b/doc/go_for_cpp_programmers.html
@@ -555,7 +555,7 @@ When you want the equivalent of a virtual function, use an interface.
 A variable which has an interface type may be converted to have a
 different interface type using a special construct called a type assertion.
 This is implemented dynamically
-at runtime, like C++ dynamic_cast.  Unlike
+at run time, like C++ dynamic_cast.  Unlike
 dynamic_cast, there does
 not need to be any declared relationship between the two interfaces.
 
@@ -589,7 +589,7 @@ must unbox using a type assertion to recover
 values of the contained type.  As the typing is dynamic rather
 than static, there is no equivalent of the way that a C++ template may
 inline the relevant operations.  The operations are fully type-checked
-at runtime, but all operations will involve a function call.
+at run time, but all operations will involve a function call.
 
 
 type iterator interface {
diff --git a/doc/go_spec.html b/doc/go_spec.html
index 25eb3c46440..e91730a0215 100644
--- a/doc/go_spec.html
+++ b/doc/go_spec.html
@@ -4698,7 +4698,7 @@ func protect(g func()) {
 	defer func() {
 		log.Println("done")  // Println executes normally even in there is a panic
 		if x := recover(); x != nil {
-			log.Printf("runtime panic: %v", x)
+			log.Printf("run time panic: %v", x)
 		}
 	}
 	log.Println("start")
diff --git a/doc/install.html b/doc/install.html
index d8fa8b468ce..09f5be5567a 100644
--- a/doc/install.html
+++ b/doc/install.html
@@ -54,7 +54,7 @@ architectures.
 
 
 

-Except for things like low-level operating system interface code, the runtime
+Except for things like low-level operating system interface code, the run-time
 support is the same in all ports and includes a mark-and-sweep garbage collector
 (a fancier one is in the works), efficient array and string slicing,
 support for segmented stacks, and a strong goroutine implementation.
@@ -419,9 +419,9 @@ to override the defaults.
 $GOARM (arm, default=6)
 
 

-	The ARM architecture version the runtime libraries should target.
+	The ARM architecture version the run-time libraries should target.
 	ARMv6 cores have more efficient synchronization primitives. Setting
-	$GOARM to 5 will compile the runtime libraries using
+	$GOARM to 5 will compile the run-time libraries using
 	just SWP instructions that work on older architectures as well.
 	Running v6 code on an older core will cause an illegal instruction trap.