for race-free programs are equivalent to the ones in that work.
</p>

<p>
The memory model describes the requirements on program executions,
which are made up of goroutine executions,
which in turn are made up of memory operations.
</p>

<p>
A <i>memory operation</i> is modeled by four details:
</p>
<ul>
	<li>its kind, indicating whether it is an ordinary data read, an ordinary data write,

<a href="#Types">types</a> must be supported.
</p>

<h2 id="Packages">Packages</h2>

<p>
Go programs are constructed by linking together <i>packages</i>.
A package in turn is constructed from one or more source files
that together declare constants, types, variables and functions
belonging to the package and which are accessible in all files
of the same package. Those elements may be

The details vary with architecture, and we apologize for the imprecision; the situation is not well-defined.
</p>

<p>
The assembler program is a way to parse a description of that
semi-abstract instruction set and turn it into instructions to be
input to the linker.
If you want to see what the instructions look like in assembly for a given architecture, say amd64, there
are many examples in the sources of the standard library, in packages such as

	and corresponding method types must unify exactly.
</li>
</ul>

<p>
When solving type equations from type constraints,
solving one equation may infer additional type arguments,
which in turn may enable solving other equations that depend
on those type arguments.
Type inference repeats type unification as long as new type
arguments are inferred.
</p>

<h3 id="Operators">Operators</h3>