-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Automatically making immutable const data reside in program memory #74
Comments
I personally am a fan of this, although here's AVR-GCC's reasoning for not doing this.
|
Also, for anybody reading, in LLVM all pointers are annotated with address spaces, and so we don't need to use anything special like |
FWIW, currently a Rust:
LLVM IR:
AVR asm:
(which ends up in However, accessing it doesn't go through Rust:
LLVM IR (of the relevant part):
AVR asm:
|
I think we should be able to do something here, what rules should define a value going into program memory? I'm thinking that all Regarding statics, I'm not sure if it'd be safe putting immutable statics into program memory. Statics are supposed to be usable from FFI, and it would be an easy mistake to declare an external static in C that is actually defined in Rust and read from it, expecting it to be in RAM, but it is actually in program memory. |
AFAIK, Rust's main concern with |
If we can't come up with a rule, I do think some kind of attribute allowing both opt-in and opt-out would be a good start. If we notice a pattern, that could be encoded in the compiler. |
Have made this issue specifically about the automatic promotion of static data to program memory by the Rust compiler itself. If we want an explicit syntax for it (such as an attribute), that is now at #84 |
Oh, I also spent some time working on this a while back, it doesn't look like I wrote anything about it. I started work on modifying the Doing this won't be too much work, but it's not as trivial as initially thought. |
Thinking about this more, we can only do this on devices that support the |
I think it would be a good idea to do this by
This way, the frontend doesn't need to know AVR specific quirks. |
I don’t know that I would try to automatically determine where a value should be stored based on |
The main thing that prompted this idea is the fact that even variables that reside in RAM must still reside in program memory (ignoring zero-initialized variables in The main difference with Rust and C++ - there is no such thing as So, my thoughts are, I think if even just one counterexample can be found, then I agree that we totally should not do this automatically. As it stands, there aren't any documented downsides, but there are known upsides such as lower memory use and faster startup time.
For what it's worth, my understanding of the proposal is that we leave static as-is and only promote constants to progmem. I guess the title of this ticket doesn't really reflect this. I believe that it might make sense to automatically promote immutable statics to program memory too, but that should be a different discussion (as it has downsides such as mucking with FFI). |
It's not. The const will be automatically promoted to a static (just like a literal): const SIZE: usize = 42;
fn a() -> &'static usize {
&SIZE
}
fn b() {
let x = &mut SIZE;
}
fn c() -> &'static usize {
&99
} This can cause confusion sometimes |
This might not play well with interior mutability. |
oof, that sounds like the counterexample I was worried about. @shepmaster do you think it could work if we write the LLVM pass such that it only promotes certain constants to PROGMEM? There may be a subset of global variables that can be safely promoted to PROGMEM. Here's a few points from the LLVM LangRef that we could leverage.
|
Yes, I think this makes sense, the problem is that I don't have enough vision to say what the accurate criteria are. |
One use case of not automatic placement of |
I've asked LLVM devs if it would be possible to implement automatic PROGMEM "distribution". What I mean is to let compiler decide which PROGMEM variables will be placed in which address space. AVR have quirks about reading across 64KB boundary, which requires separate instruction |
For reference, here is @luqasz's thread http://llvm.1065342.n5.nabble.com/llvm-dev-Built-in-progmem-variables-in-AVR-td131773.html |
It would be useful to have a way of marking a string constant (a
&'static [u8]
?) explicitly to ensure it is put into PROGMEM. For reference, it can be done in C by using thePROGMEM
macro on the definition of aconst uint8_t[]
:and then you can use
pgm_read_byte
to read it one by one.Out of scope: Automatically promoting
static
values to PROGMEM.The text was updated successfully, but these errors were encountered: