Going to express this in C terms since that language has a longer history in the space. For little processors like AVR, and bigger but specialized ones (e.g. DS

Going to express this in C terms since that language has a longer history in the space. For little processors like AVR, and bigger but specialized ones (e.g. DSPs), standard ANSI C is neither necessary nor sufficient. For instance, nobody is ever going to do IEEE754 floating point arithmetic on an AVR, or on a DSP56000. But these processors have other properties that a programmer is likely to want to use that are not expressible in standard C (sometimes, not even with intrinsics); for the most common cases, C has the TR18037 extensions¹. In the AVR case, on the biggest chips a RAM address takes 2 bytes while a flash address is 3 bytes, and on the smallest a RAM address is 1 byte while a flash address is 2, and of course the values overlap (flash-address-0xFE points to different memory than RAM-address-0xFE), and the indirection code is different. So how big is a plain 'char *', and how do you dereference it? On a small AVR you don't want to be wasting precious memory storing and copying 2 bytes when 1 will do, and you sure don't want a run-time test on every dereference —​ if you had the cost/time/battery for that you wouldn't have picked² a small AVR in the first place. So you need to be able to tell the compiler what kind of memory a pointer points to. The big free toolchains (gcc/llvm) don't pay much attention to non-mainstream processors, which is why a handful of commercial compilers still exist. I suppose (not being a Rust expert) that a Rust compiler could figure out that a non-mut 'static can go in flash, and track address spaces, and auto-genericize functions that take a reference… but I'll bet it doesn't, yet. ¹ http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1169.pdf http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1169.pdf ² no pun intended originally, but I'm leaving it and gratuitously calling attention to it.