Am Sonntag, dem 01.12.2024 um 12:41 +0100 schrieb Bertho Stultiens: > On 11/30/24 03:28, Curtis Dutton wrote: > > I wrote the initial hal port code. there is no reason that I know > > of > > why it is required. I was following what I saw in other hal code > > without really knowing if it was needed. > Rip it out! > Done. See PR#3199 for details. > > Not all instances of volatile are gone. Only there where they are > used > as scalar arguments or return value. > > > > If the tests pass it's probably fine. I run components daily that > > depends upon hal_port so I'll catch it (and help with fallout / > > fixing ) if something goes wrong. > Tests pass. > > There should be a review to look into the other instances of > volatile. > I've seen the use of some atomics/memory barriers in the code, but > there > are many pointers used where volatile changes the code's load/store > behavior, which may be essential for shared memory to work properly. > > The code would actually become faster if more volatile could be > eliminated. Maybe another time? >
AFAIK best practice would be to get rid of all volatile types in datastructures and interfaces (what does it mean to call a function that takes a volatile something as argument?) and use volatile-cast at access-time. This could be done in the C++ part via template functions and in C with equivalent macros. I think even when accessing shared memory, volatile won't be needed in most cases. https://github.com/torvalds/linux/blob/master/Documentation/process/volatile-considered-harmful.rst regards Robert _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
