mån 2024-12-02 klockan 12:18 +0100 skrev Robert Schöftner: > 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. There is no volatile cast so will also cast type and then there is a possibility to by misstake cast to wrong type.
If parameter is passed by value create a local variable with volatile modifier and assign to this is an option. Not sure it will make any difference on performance or code. If address to something in shared memory is not volatile a read or write will to memory is guaranteed? Nicklas Karlsson _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
