-
Notifications
You must be signed in to change notification settings - Fork 62
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
Volatile atomic #682
base: master
Are you sure you want to change the base?
Volatile atomic #682
Conversation
@mrutt92 foresee any issues doing this? |
It seems reasonable to me. Adding the volatile modifier to the pointer is typical for defining functions like these. If you're writing c++ I encourage using std::atomic if you can... then you don't need to think about this volatile nonsense. Could you post some example C and assembly showing the bug? |
Ya the test added will fail if you switch out "int* lock_ptr = &lock;" for "volatile int* lock_ptr = &lock;"
|
This might be more informative, you can see the difference in ASM here:
|
I've been encountering an issue mixing loads and amos to the same address. I've convinced myself it's a coding issue rather than a hardware issue, with the compiler not tracking the inline assembly dependencies correctly. Making the pointer volatile seems to make the accesses sane. But then compiling with C++ -fno-permissive, causes the following:
This PR makes the pointer parameter for the bsg_amo_add volatile so that we can compile this code correctly. It also adds a test demonstrating the issue