# Accelerator-side code and stability

**URL:** <https://forum.modular.com/t/accelerator-side-code-and-stability/3099>\
**Category:** Mojo 1.0 Beta\
**Tags:** discussion\
**Created:** [May 21, 2026, 5:37pm UTC](https://forum.modular.com/t/accelerator-side-code-and-stability/3099 "2026-05-21T17:37:57Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![owenhilyard](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.modular.com/owenhilyard/32/41_2.png) [@owenhilyard](https://forum.modular.com/u/owenhilyard)\
**Post date:** [May 21, 2026, 5:37pm UTC](https://forum.modular.com/t/accelerator-side-code-and-stability/3099/1 "2026-05-21T17:37:57Z")

</div>

As we approach 1.0, I think it needs to be determined what stdlib code is supported on accelerators and what is not, or at least a framework created for discussing this for a particular stdlib feature.

For instance, `List`’s `UnsafePointer` uses the generic address space, which means that GPU-side code which wishes to use `List` can’t place it in shared memory. The same is true of most other stdlib collections. `Span` also has this address space issue.

[GDS](https://docs.nvidia.com/gpudirect-storage/api-reference-guide/index.html) and other Magnum IO libraries from NVIDIA mean that users can have a reasonable expectation that `std.io.file.open` works on a properly configured GPU. `print` works on many targets, but I expect that potential future targets which are less CPU-like (ex: AMD XDNA) may make implementing it tricky at best. What does `stack_allocation` mean on a dataflow chip like Groq? What does `getenv` and `setenv` do on an accelerator? `fstat`? Almost the entirety of `os`? `pwd`? `subprocess`? Some parts of `pathlib.Path` are perfectly fine, others run into the same problems `File` does. Can I `Python.import("max")` on a GPU? How can I interact with `asyncrt` on a GPU?

Especially as parts of the stdlib start to get marked `stable`, I think there needs to be consideration and documentation of what `stable` means for different targets. This also applies to MAX kernels, where different kernels are at very different levels of readiness on different targets. Have there been any internal discussions about how to handle this since the last public discussions of stabilizing the stdlib?

---

<div class="post-metadata">

**Author:** ![jbemmel](https://avatars.discourse-cdn.com/v4/letter/j/5daacb/32.png) [@jbemmel](https://forum.modular.com/u/jbemmel)\
**Post date:** [May 22, 2026, 1:18am UTC](https://forum.modular.com/t/accelerator-side-code-and-stability/3099/2 "2026-05-22T01:18:03Z")

</div>

Besides documenting, is there a need to formalize this somehow?

I could imagine a framework with trait definitions for common platform archetypes

trait GenericCPU(Platform)  
comptime SUPPORTS\_SHARED\_LIST\_ADDRESS\_SPACE: Boolean = True

trait NVidiaxxx(Platform)  
_comptime SUPPORTS\_SHARED\_LIST\_ADDRESS\_SPACE: Boolean = False_

trait AMD\_XDNA(Platform)  
…