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 \(O(1)\). 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.

Arena *arena_alloc(void);
void arena_release(Arena *arena);
void arena_set_auto_align(Arena *arena, u64 align);

u64 arena_pos(Arena *arena);

void *arena_push_no_zero(Arena *arena, u64 size);
void *arena_push_aligner(Arena *arena, u64 alignment);
void *arena_push(Arena *arena, u64 size);

void arena_pop_to(Arena *arena, u64 pos);
void arena_pop(Arena *arena, u64 size);
void arena_clear(Arena *arena);

#define PushArrayNoZero(arena, type, count) (type *) \
    arena_push_no_zero((arena), sizeof(type) * (count))
#define PushArray(arena, type, count) (type *) \
    arena_push((arena), sizeof(type) * (count))

the simplest arena allocator will look something like

static unsigned char *arena_buffer;
static size_t arena_buffer_length;
static size_t arena_offset;

void *arena_alloc(size_t size) {
    // Check to see if the backing memory has space left
    if (arena_offset+size <= arena_buffer_length) {
        void *ptr = &arena_buffer[arena_offset];
        arena_offset += size;

        // Zero memory
        memset(ptr, 0, size);
        return ptr;
    }
    return NULL;
}

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:

extern _m128 _mm_add_ps( _m128 _A, _m128 _B);

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.

#
# A simple makefile for managing build of project composed of C source files.
#


# It is likely that default C compiler is already gcc, but explicitly
# set, just to be sure
CC = gcc

# The CFLAGS variable sets compile flags for gcc:
#  -g        compile with debug information
#  -Wall     give verbose compiler warnings
#  -O0       do not optimize generated code
#  -std=c99  use the C99 standard language definition
CFLAGS = -g -Wall -O0 -std=c99

# The LDFLAGS variable sets flags for linker
#  -lm   says to link in libm (the math library)
LDFLAGS = -lm

# In this section, you list the files that are part of the project.
# If you add/change names of source files, here is where you
# edit the Makefile.
SOURCES = demo.c vector.c map.c
OBJECTS = $(SOURCES:.c=.o)
TARGET = demo


# The first target defined in the makefile is the one
# used when make is invoked with no argument. Given the definitions
# above, this Makefile file will build the one named TARGET and
# assume that it depends on all the named OBJECTS files.

$(TARGET) : $(OBJECTS)
    $(CC) $(CFLAGS) -o $@ $^ $(LDFLAGS)

# Phony means not a "real" target, it doesn't build anything
# The phony target "clean" is used to remove all compiled object files.

.PHONY: clean

clean:
    @rm -f $(TARGET) $(OBJECTS) core

Subsitutions defined toward top of the file, e.g. (CFLAGS = -g -Wall), and are similar to #define in C . 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

target-name : dependencies
    action

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

go mod init your/module

This will create a new file `go.mod`

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

var x int = 10
var y float64 = 30.2
var sum1 float64 = float64(x) + y
var sum2 int = x + int(y)
fmt.Println(sum1, sum2) // 40.2  40

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

var s []int             // nil slice
s := []int{1, 2, 3}     // slice literal
s := make([]int, 5)     // length 5, capacity 5
s := make([]int, 0, 10) // length 0, capacity 10

s = append(s, 10)           // single element
s = append(s, 1, 2, 3)      // multiple elements
s = append(s, other...)     // append slice
clear(s)                    // zero all elements (Go 1.21+)

s[low:high]     // items low through high-1
s[low:]         // items low through end
s[:high]        // items beginning through high-1
s[:]            // copy of entire slice
s[low:high:max] // control capacity of new slice

copy(dest, src)        // copies min(len(dest), len(src)) elements
copy(dest, src[1:])    // copy from middle of src

array := [4]int{1, 2, 3, 4}
slice := array[:]              // array to slice
array2 := [4]int(slice)       // slice to array (new memory)
arrayPtr := (*[4]int)(slice)  // slice to array pointer (shared memory)

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.

// Map literal
m := map[string]int{"Alice": 10, "Bob": 20}

// Using make
m := make(map[string]int, 10) // Capacity 10
m["Charlie"] = 30

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

type Person struct {
    Name string
    Age  int
}
p := Person{Name: "Alice", Age: 30}
fmt.Println(p.Name)

Anonymous structs are inline struct definitions:

pet := struct {
    Name string
    Kind string
}{Name: "Fido", Kind: "dog"}

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

x := 10
p := &x
fmt.Println(*p) // 10

Inner-scope variables can shadow outer-scope ones:

x := 10
if x > 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.

package main

import "fmt"

func main() {
    a := 20
    f := func() {
        fmt.Println(a)
        a = 30
    }
    f()
    fmt.Println(a)
}

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:

var * int
fmt.Println(x == nil)			// prints true
fmt.Println(*x)					// panics

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.

var x = new(int)
fmt.Println(x == nil)			// prints false
fmt.Println(*x)					// prints 0

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.

type person struct {
    FirstName string
    MiddleName *string
    LastName string
}

p := person {
        FirstName: "Pat",
        MiddleName: "Perry", // This line will not compile
        LastName: "Peterson",
    }

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:

func makePointer[T any](t T) *T {
  return &t
}

which allows one to write the previous code as

p := person {
        FirstName: "Pat",
        MiddleName: makePointer("Perry"),
        LastName: "Peterson",
    }

**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