Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
AVR is Harvard architecture #53
One problem I've run into (see #47) is that Rust sometimes generates static lookup tables from code, then the generated AVR assembly tries accessing that data using
First off, we need to know when to compile an LLVM IR
However, this is problematic because Rust code is free to take pointers to static strings in the form of
Putting it all together, my proposal for handling all this would be:
This should be implementable by:
I believe the way this is implemented in other targets is via numbered address spaces. Address space
We have an AVR-specific method for this already -
I haven't looked at your patch in-depth yet but these are my thoughts
That's easy enough - we can teach Rust to emit global variables with address space
Maybe an attribute? I'm not entirely certain.
LLVM does have target-specific attributes, and they are also quite easy to add.
I believe that all loads/stores should use data memory (
Can you point me to where in GCC it does that? Looks like we're definitely going to need to implement that.
I think that that is caused by the fact that the switch resides in program memory but it is not marked as such (via an address space attribute).
In this case, Rust is probably emitting a switch lookup table and neglecting to put an address space attribute on it.
referenced this issue
May 13, 2017
I haven't dived into GCC's source yet, but here's an example showing this copying in action.
C source file:
Object file: note that string literal is in
Linked exe: note
Is this issue why I can't use byte strings?
Code such as
... which produces assembly like ...
works, but code such as
which produces assembly like
and the .data section:
sends null bytes only.
Interestingly, with --release it works either way -- it again stores the data inside the code with optimization, so I assume that's why it works.