Only requires an offset or pointer to state the end of the last allocation. To allocate some memory from the arena it is as simple as moving the offset (or pointer) forward. The allocation has the complexity of . Due to being the simplest allocator possible, the arena allocator does nto allow the user to free certain blocks of memory. The memory is usually freed all at once.

An arena is like a stack with extensions, e.g. it can be named.

the simplest arena allocator will look something like

While this is as simple as it gets, there are two issues with the basic approach * You cannot reuse this procedure for different arenas. * The pointer returned may not be aligned correctly for the data you need. The first issue can be solved by coupling the data into a structure and passing that to the procedure =arena_alloc=.

Intrinsics appear like regular libary functions. You include the relevant header, and then you can use it just like any other lib. E.g. assuming a visual c++ compiler, if you wanted to add four float numbers to another four numbers, you would include the xmmintrin.h header which contains the following declaration for the _mm_add_ps intrinsic:

However unlike lib functions, intrinsics are implemented directly in compilers. The example SSE intrinsic typically compiles to a single instruction, x86 and amd64 instructions. For the time it takes CPU to call a library function, it might have completed dozen of these functions.

For all x86 the current best practice is to use <immintrin.h> which loads in the the correct compatible instruction set.

• __MMX__ -- X86 MMX :: mmintrin.h
• __SSE__ -- X86 SSE :: xmmintrin.h
• __SSE2__ -- X86 SSE2 :: emmintrin.h
• __VEC__ -- altivec functions :: altivec.h
• __ARM_NEON__ -- ARM Neon functions :: arm_neon.h

It is common practice to copy and modify old makefules rather than generating new ones from scratch.

Subsitutions defined toward top of the file, e.g. (CFLAGS = -g -Wall), and are similar to #define in . It can be referenced later with $(CFLAGS).

Example macros: - OBJECTS = $(SOURCES:.c=o) - Defines the OBJECTS macro to be the same as the SOURCES macro except that every instance of .c is replaced with .o. - $@: - built-in, name of the current target - $^: - built-in, current targets list of dependencies

Written in the following form

where the target name is the name of the file that will be produced when this target is built. The first target listed in a make file is the default target, meaning it is invoked by make with no args.

The clean target in the example does not fit the pattern which is previously described of targets. It does not create a file named clean, rather it is a shortcut for running a command whcih cclears out the projects build files. These commands are listed as dependencies of .PHONY which allows Make to run the target without any dependency checks.

Within a new directory, initialize a module with

This will create a new file `go.mod`

Go does not support automatic type conversion. All variable types need to be converted to interact.

Different qoutes are used for different contexts.

The double qoute " will be used to create string literals, while the backtick is used to create raw string literals. The single qoute ' is used to create runes, a single unicode point. E.g. r := '學'.

• Slices will have a zero value of nil and is only comprable with nil and ==.
• Modifying shared slices will affect all references.
• Length can differ from capacity

1. `var` declaration (nil slice): When size unknown, no initial data 2. Slice literal: When starting values are known 3. `make`: - With length: For buffers or exact size known - Zero length + capacity: For growing slices

- Capacity doubles when < 256 - Growth slows to ~25/for larger slices - Use full slice expression `s[low:high:max]` to prevent capacity issues - Be careful with shared memory when slicing

- `slices.Equal(a, b)`: Compare if length and elements match - `slices.EqualFunc(a, b, fn)`: Custom comparison function

Maps are declared as `map[keyType]valueType`. A `nil` map (e.g., `var m map[string]int`) cannot be written to. Use `make` or a map literal for writable maps.

Structs are user-defined types with fields. Define them with `type` and access fields using dot notation.

Anonymous structs are inline struct definitions:

Use `&` to get a pointer and `*` to dereference. `nil` pointers cannot be dereferenced.

Inner-scope variables can shadow outer-scope ones:

 5 {
    x := 5
    fmt.Println(x) // 5
}
fmt.Println(x) // 10]]>

These are functions defined _within_ a function, and are able to access and modify variables declared in the outer function. Closures allow you to pass fome function state to another function. These can also be returned from a function.

Anonymous function `f` can read and write `a` even though `a` is not passed in to the function. Using `:=` instead of `=` inside the closure creates a new `a` that ceases to exist when the closure exits.

Standard address (`&`) and indirection/dereferencing (`*`) operators. Pointer tricks such as _pointer arithmetic_ that you can do in C are not allowed in go.

Before dereferencing a pointer, you must make sure it is non-nil, otherwise the program will panic if you attempt to dereference a `nil` pointer:

The pointer type can be based on any type, and the built in function `new` creates a pointer variable which returns a pointer to a zero-value instance of the type.

However, the `new` function is rarely used.

For structs use `&` before a struct literal to create a pointer instance. When you need a pointer to a primitive type, declare a variable and then point to it.

Constant literals cannot use `&` because they don't have a memory address, e.g.

There are two ways around the problem. The first is to introduce a variable to hold the constant. The second is to write a generic helper function that takes a parameter of any type and returns a pointer to that type:

which allows one to write the previous code as

**NOTE**: The only time you should use pointer parameters to modify a variable is when the function expects an interface, e.g. JSON.

Within the go runtime, a map is implemented as a pointer to a struct, so passing a map to a function means that you are copying a pointer. Thus changes made to a map within the functions are reflected in the original.

**NOTE**: maps for input parameters or return values should be carefully considered. On an API design level, they are a bad choice because they say nothing about the values contained within. In general one should prefer a struct for these cases.

A slice is more complicated. Any modification to a slices contents within a function is reflected in the original, but using append to change the length of the array is not, even if the slice has a capacity greater than its length. This is due to slice being implemented a struct with three fields:

• int for length
• int for capcity
• a pointer to a block of memory