Support discontinuous memory

[digitalentity]

Often MCUs have several memory areas, e.g. STM32H7 (#5369) has:

• AXI SRAM (0x24000000) - 512KB continuous memory, currently available to TinyGo as RAM (bss and heap).
• D2 SRAM (0x30000000) - 288KB total (128+128+32), same silicon as AXI SRAM, just a different power domain (stays up in D2 low-power states, AXI SRAM doesn't). TinyGo currently doesn't have access to it.
• D3 SRAM (0x38000000) - SRAM4, 64KB, D3 domain, survives even deeper sleep (Stop mode), typically used for BDMA buffers since BDMA can only reach D3. TinyGo currently doesn't have access to it.

AXI + D2 + D3 don't form a continuous memory region, so they can't be easily bundled together and made available to TinyGo, but this also means we're effectively wasting 352 Kb of RAM.

Another caveat is that not all memory is made equal.

STM32F7 and some H7 CPUs for example, have TCM memory which can be accessed at 0 wait states, unlike the general RAM which is slower. DMA can't generally be used on TCM though. Similarly on STM32H75x - D3 is the only memory that survives clock stop and the only memory that supports BDMA.

This means we need to support some kind of NUMA memory allocation where we can either allocate from a particular memoy region at run-time or use //go: pragmas to place a statically allocated buffer into a defined memory region. GC and heap allocator will also need to support discontinuous memory.

A relatively simple approach could be as follows:

1. We define additional memory sections (target-specific) and create a //go:linksection pragma to control where the variable goes.
2. We support some sort of arena allocator for non-heap memory allocated at run-time as an unsafe.Pointer. Pointers into this memory are never GC'd.

[digitalentity]

@knieriem this might be interesting for you too since you're working on DMA-heavy Eth support on H7.

[deadprogram]

I am running into this right now with the ESP32, as well. In that case there are some ranges of memory right in the middle of everything that is used for DMA operations by the radio blobs.

[digitalentity]

A separate non-GC'd allocator for DMA buffers would be relatively easy to implement. I can have a crack at it tomorrow.

[digitalentity]

@deadprogram an MVP that unblocks ESP32 is //go:section + linker script changes...

[knieriem]

@digitalentity for ETH support, i am using //go:section too, like in:

//go:section .ram_nocache
var txDesc [4]gmac.DMADescTx

(... from eth.go)

Then, in the .ld file, I define

MEMORY
{
  FLASH_TEXT (rx) : ORIGIN = 0x08000000, LENGTH = 1024K
  RAM (xrw)       : ORIGIN = 0x24000000, LENGTH = 128K
  D2_AHB_SRAM1 (rw)	: ORIGIN = 0x30000000, LENGTH = 16K
}

_stack_size = 4K;

INCLUDE "targets/arm.ld"

/* define output sections */
SECTIONS
{
    .ram_nocache (NOLOAD):
    {
        . = ALIGN(4);
        *(.ram_nocache)
        *(.ram_nocache*)
        . = ALIGN(4);
    } >D2_AHB_SRAM1
}

[digitalentity]

We can have arenas implemented like this:

package runtime

import "unsafe"

type Arena struct {
    start uintptr
    end   uintptr
    curr  uintptr
    lock  atomicLock // interruptLock-style spinlock
}

func NewArena(start, size uintptr) *Arena {
    return &Arena{
        start: start,
        end:   start + size,
        curr:  start,
    }
}

// Alloc allocates memory with the specified alignment, returning an unsafe.Pointer.
// align must be a power of two. Safe to call concurrently, including from interrupt
// handlers.
func (a *Arena) Alloc(size, align uintptr) unsafe.Pointer {
    a.lock.Lock()
    defer a.lock.Unlock()

    addr := (a.curr + align - 1) &^ (align - 1)
    if addr+size > a.end {
        return nil
    }
    a.curr = addr + size
    return unsafe.Pointer(addr)
}

// AllocT allocates a zeroed T from the arena. Panics on exhaustion.
func AllocT[T any](a *Arena) *T {
    var zero T
    p := a.Alloc(unsafe.Sizeof(zero), unsafe.Alignof(zero))
    if p == nil {
        runtimePanic("arena: out of memory")
    }
    obj := (*T)(p)
    *obj = zero // arena memory is not guaranteed zeroed (raw SRAM, and reuse isn't freed/cleared)
    return obj
}

Init like this:

//go:extern _d2_sram_start
var d2SramStartSymbol [0]byte
//go:extern _d2_sram_end
var d2SramEndSymbol [0]byte

var DMAArena *Arena

func initArenas() {
    start := uintptr(unsafe.Pointer(&d2SramStartSymbol))
    size := uintptr(unsafe.Pointer(&d2SramEndSymbol)) - start
    DMAArena = NewArena(start, size)
}

And use it like this:

var txDesc *gmac.DMADescTx = runtime.AllocT[gmac.DMADescTx](machine.DMAArena)

This code is far from being prod ready - GC is unaware of these regions and will not consider anything referenced from here as used, the atomicLock is a placeholder etc.

[deadprogram]

Some of my own work on this is here #5510 combined with an unpushed branch in espradio. It is very specfic to ESP32, so the general conversation here is really interesting.

[digitalentity]

I'm curious about people's use-cases. I see several possibilities:

1. Statically allocated buffers. //go:section + linker script magic is sufficient in this case (although not portable).
2. Allocate-once strategy. Allocation happens at run-time, but buffers are never released. The arena bump allocator above would be sufficient.
3. Allocate/free strategy. Buffers are allocated and freed as needed. This is the most complex scenario where we would need to decide whether we want to keep this memory separate with explicit alloc/free; or wire it into the TinyGo's GC. Both options has advantages and disadvantages...

I think the pattern similar to sync.Pool would have the best of all worlds. It's portable, supports "returning" objects into the pool when they are no longer needed and is a standard idiomatic go pattern. In the DMA non-uniform memory the arena.Pool would be backed by the bump allocator, so no real "freeing" memory happens and GC doesn't have to be involved.

@deadprogram wdyt?

[aykevl]

It looks like this issue is about two different things:

• Discontinuous memory. This can be implemented without any user facing changes, just by updating the GC to work over multiple address ranges.
• NUMA memory, where some memory is special in some way.

At the moment the assumption is that all memory used in DMA operations (such as spi.Tx on many chips) can be any heap allocated memory. We could change this, and maybe we need to, but if we do that's a breaking change and we need to think about whether we want to do that.

While arenas are a possibility, I would strongly advise against it. They don't play well with the GC (unless we make the GC also scan those areas at which point it's easier to just make the GC support multiple ranges) and an API would either have to be inherently unsafe or just return []byte. If they are misused, it's very difficult to catch bugs since it will lead to memory corruption instead of a panic for example.

[digitalentity]

At the moment the assumption is that all memory used in DMA operations (such as spi.Tx on many chips) can be any heap allocated memory.

Yes, we do and that's totally wrong for a lot of MCUs out there (STM32 and ESP32 being two examples). I would prefer to keep the allocators GC-aware, but then we have the question - how do we tell the compiler that we want this varible allocated exclusively form a particular memory area? Arena allocator + sync.Pool is a cheap way of doing it. When, at some point, GC will be made aware of "special" kinds of memory, the allocator + sync.Pool code won't really have to change.

[dgryski]

I think we need non-contiguous memory for wasip3 as well. Will need to double check that..