In order to directly support the TLSF allocator repo, might be better to add it as a submodule with an include wrapper for the necessary coupling to the SDK's expected malloc interface. On the other hand this might not be a good idea, since I plan to cut down the TLSF implementation to only support 32-bit and change the alignment from 4 to 8 bytes.
I'd imagine that there might be some discussion to be had around the implementation of the CMake side of things. I'm really not overly familiar with CMake so there may well be better ways of doing what I've done in this PR.
Something else to think about is adding performance tests/benchmarking in the form of a standard suite to run against a given allocator implementation. This gives both SDK devs and users a decent idea of how the supported allocators run and their practical usage.
TODO
[x] Implement void TrackHeapUsage(ptrdiff_t alloc_incr) for TLSF
[x] Implement void GetHeapUsage(HeapUsage* usage) for TLSF.
[ ] Migrate TLSF to a git submodule and create interfacing wrapper (option 1).
[ ] Refactor TLSF to support only 32-bit and 8-byte alignment (option 2).
[x] Write documentation for CMake variable usage and supporting a new allocator.
[x] Write documentation for implementing a new allocator into the SDK or overriding the CUSTOM one.
[x] Remove the mention of needing to support multiple allocators in README.md.
[ ] Squash commits to make the changes and history more palatable.
[x] Fix formatting
[x] Remove SMD defines
[x] Make CMake flag naming consistent
Notes
I've used TLSF before a while ago for an undergrad thesis project and it showed promise over the standard GlibC allocator and will subsequently perform much better than the current implementation in the SDK.
Changes
This adds support for multiple allocator implementations in tandem with a CMake switch
-D PSN00BSDK_LIBC_ALLOCATORwith the current implementations:To Consider
In order to directly support the TLSF allocator repo, might be better to add it as a submodule with an include wrapper for the necessary coupling to the SDK's expected malloc interface. On the other hand this might not be a good idea, since I plan to cut down the TLSF implementation to only support
32-bitand change the alignment from4to8bytes.I'd imagine that there might be some discussion to be had around the implementation of the CMake side of things. I'm really not overly familiar with CMake so there may well be better ways of doing what I've done in this PR.
Something else to think about is adding performance tests/benchmarking in the form of a standard suite to run against a given allocator implementation. This gives both SDK devs and users a decent idea of how the supported allocators run and their practical usage.
TODO
void TrackHeapUsage(ptrdiff_t alloc_incr)forTLSFvoid GetHeapUsage(HeapUsage* usage)forTLSF.TLSFto a git submodule and create interfacing wrapper (option 1).TLSFto support only32-bitand8-bytealignment (option 2).CUSTOMone.README.md.Notes
I've used TLSF before a while ago for an undergrad thesis project and it showed promise over the standard GlibC allocator and will subsequently perform much better than the current implementation in the SDK.