llvm-mos-sdk
Public Member Functions | List of all members
soa::Array< T, N > Class Template Reference

#include <soa.h>

Public Member Functions

constexpr Array (std::initializer_list< T > Entries)
 
constexpr Array ()=default
 
template<uint8_t M>
constexpr Array (const Array< T, M > &Other)
 
constexpr Ptr< T > operator[] (uint8_t Idx)
 
constexpr Ptr< const T > operator[] (uint8_t Idx) const
 
constexpr ArrayConstIterator< T, N > begin () const
 
constexpr ArrayConstIterator< T, N > end () const
 
constexpr ArrayIterator< T, N > begin ()
 
constexpr ArrayIterator< T, N > end ()
 
constexpr uint8_t size () const
 

Detailed Description

template<typename T, uint8_t N>
class soa::Array< T, N >

An array implemented as a struct of arrays.

Consider a normal C array, T array[N]. If sizeof(T) > 1, then to access the kth byte of the Ith entry requires evalutating the expression array + sizeof(T) * I + k. Even if k and array (that is, it's address) are constant, evaluating the index still requires a multiply and 16-bit addition in the worst case.

You could think of this as the following multidimensional array: uint8_t array[Idx][ByteIdx]. The first Idx ranges over N, while the second ranges over sizeof(T).

Instead, the indices of this array could be swapped: uint8_t array[ByteIdx][Idx]. Then, accessing the kth byte of element I would involve the expression array + N * k + I. But, very commonly array and N * k are constants! This expression can then be computed implicitly by the absolute indexed addressing mode. This kind of layout is commonly performed by hand by experienced C and assembly-language 6502 programmers.

This library organizes its bytes in precisely the way described above, but with similar syntax to a regular C++ array. To provide a performance benefit you must ensure the array's address is at a link-time constant memory location. Simlarly, no pointers can be formed into the contents of an array element, otherwise the offset into an array element wouldn't be a compile-time constant. Also, this class loses its performance benefit, and indeed, may hurt performance, if accessed through a pointer to soa::Array, since the addressing described above then intrinsically involves 16-bit pointer arithmetic.

Because the representation of the elements is broken apart, only trivial types with standard layouts are supported (think C-style types). It must have an alignment requirment of 1 byte, and it must not be volatile.

Constructor & Destructor Documentation

◆ Array() [1/3]

template<typename T , uint8_t N>
constexpr soa::Array< T, N >::Array ( std::initializer_list< T >  Entries)
inlineconstexpr

◆ Array() [2/3]

template<typename T , uint8_t N>
constexpr soa::Array< T, N >::Array ( )
constexprdefault

◆ Array() [3/3]

template<typename T , uint8_t N>
template<uint8_t M>
constexpr soa::Array< T, N >::Array ( const Array< T, M > &  Other)
inlineconstexpr

Member Function Documentation

◆ begin() [1/2]

template<typename T , uint8_t N>
constexpr ArrayIterator<T, N> soa::Array< T, N >::begin ( )
inlineconstexpr

◆ begin() [2/2]

template<typename T , uint8_t N>
constexpr ArrayConstIterator<T, N> soa::Array< T, N >::begin ( ) const
inlineconstexpr

◆ end() [1/2]

template<typename T , uint8_t N>
constexpr ArrayIterator<T, N> soa::Array< T, N >::end ( )
inlineconstexpr

◆ end() [2/2]

template<typename T , uint8_t N>
constexpr ArrayConstIterator<T, N> soa::Array< T, N >::end ( ) const
inlineconstexpr

◆ operator[]() [1/2]

template<typename T , uint8_t N>
constexpr Ptr<T> soa::Array< T, N >::operator[] ( uint8_t  Idx)
inlineconstexpr

◆ operator[]() [2/2]

template<typename T , uint8_t N>
constexpr Ptr<const T> soa::Array< T, N >::operator[] ( uint8_t  Idx) const
inlineconstexpr

◆ size()

template<typename T , uint8_t N>
constexpr uint8_t soa::Array< T, N >::size ( ) const
inlineconstexpr

The documentation for this class was generated from the following file: