So, this heap thing

[reinvantveer]

Seeing how far I can stretch this - alloc::vec::Vec does not require the std lib and is immensely helpful in dynamic data wrangling. But, it requires something more than just Vec::new() I found out:

error: no global memory allocator found but one is required; link to std or add `#[global_allocator]` to a static item that implements the GlobalAlloc trait.

error: `#[alloc_error_handler]` function required, but not found.

note: Use `#![feature(default_alloc_error_handler)]` for a default error handler.

I did find pub unsafe fn heap() -> &'static mut [u8] but this appears to just hand me a slice of memory available for dynamic allocation.

So maybe this is beyond the capabilities here, but is there a chance to use, say, Box and Vec from the alloc compiler crate?

[reinvantveer]

I guess the #![feature(default_alloc_error_handler)] would be as easy to implement (as a dummy) as #[panic_handler] (maybe even in the same function???)

[reinvantveer]

Hm no looking at https://doc.rust-lang.org/std/alloc/trait.GlobalAlloc.html#example this requires something else. But the example there makes heavy use of stdlib stuff

[ricky26]

The heap() function returns all the RAM which isn't statically allocated. There's probably a GlobalAlloc implementation which takes a fixed slice as the heap. A quick Google suggests something like https://crates.io/crates/wee_alloc could work.

#![feature(default_alloc_error_handler)] is an alternative to implementing #[alloc_error_handler] IIUC.

[reinvantveer]

Updated the PR description with a small todo-list, let me know if something else comes to mind.

[parasyte]

This is an interesting thread because I have been looking at options for building a GlobalAlloc implementation on Nintendo 64. Some day I want to use rust-mega-drive to bootstrap an SDK for Atari Jaguar, and I'll want an allocator on that platform as well.

It's trivial to implement a toy bump allocator for testing alloc::collections on your target. See this playground example for a minimal allocator setup.

For the GlobalAlloc trait, the alloc and dealloc methods can be implemented with any type that has interior mutability. This is usually a Mutex, but you can also use the UnsafeCell family of types, which is what the playground example does.

Bump allocators are not an ideal allocator design for robust software. And this is why I've been exploring available options. I do have atomics on N64, so it's easy enough to use crates like spin to provide a Mutex. In your case with the 68000, you need to implement Sync with a platform-specific interrupt inhibit method. In short, you can use either wee_alloc or linked-list-allocator. You just have to disable default features and implement the GlobalAlloc trait yourself.

[reinvantveer]

Hi @parasyte thanks for your sharing your thoughts on this! I also saw your suggestions on #7 and I'll look into them soon. UnsafeCell sounds like a better fit - I doubt anyone would benefit from multiple threads on this platform. spin and linked-list-allocator all require something out of the box that is unavailable for m68k targets thus far, usually something like atomics, a different Rust nightly version or full-blown 32-bit multiplication (tracking issue #4).

The Atari Jaguar looks awesome. The whole Tom & Jerry ASIC situation sounds like quite a challenge! I've been doing some stuff on the Docker end that may be of interest: I recently published a generic m68k toolchain image based on @ricky26 's fixes in this Dockerfile in a working branch that may be helpful and can help you save a couple of hours compiling llvm and rust.

[parasyte]

That docker image is excellent! Thank you for that, it should really reduce the entry barrier for Rust on m68k platforms!

The lack of intrinsics for #4 is too bad, but understandable. I'm surprised that linked-list-allocator needs 32-bit multiplies, but what can you do?

[reinvantveer]

Yeah the 32-bit multis are somewhere far under the hood of either rustc or LLVM, I havent seen any direct trace of them so far. On a good note: I'm pretty proud that I managed to implement the alloc crate with the unsafe cell implementation, to be honest I had quite the struggle with the borrow checker and I don't seem to get rid of #![feature(const_mut_refs)].